1. User's Guide
  2. Using the CellCLI Utility

7 Using the CellCLI Utility

You use the Cell Control Command-Line Interface (CellCLI) utility to manage Oracle Exadata System Software.

CellCLI provides many of the features that are provided with SQL*Plus, including the use of script files.

Related Topics

7.1 Overview of the CellCLI Utility

The Cell Control Command-Line Interface (CellCLI) utility is the command-line administration tool for Oracle Exadata System Software.

CellCLI runs on each cell to enable you to manage an individual cell. You use CellCLI to start and stop the cell, to manage cell configuration information, to enable or disable cells, and to manage objects in the cell environment.

The command-line utility is already installed when Oracle Exadata Storage Server is shipped.

Parent topic: Using the CellCLI Utility

7.1.1 Starting CellCLI

You can start CellCLI from the operating system command line on the cell that you want to manage or remotely from a network-attached client using Secure Shell (SSH).

Syntax

The command-line syntax is as follows:

cellcli [port_number] [-n] [-m] [-xml] [-v | -vv | -vvv] [-x] [-e command]

The port_number in the preceding command specifies the HTTP port number of the Management Server (MS) for the cell. If the port_number argument is omitted, then the CellCLI utility uses the value assigned to the HTTP_PORT variable in the cellinit.ora file on the cell. If the HTTP_PORT variable in the cellinit.ora file is not set, then the port number defaults to 8888.

Options

The following options can be used with the CellCLI command:

  • -n — Runs the CellCLI utility in non-interactive mode. This option suppresses the command prompt and disables the command-line editing features.

  • -m — Runs CellCLI monitor (read-only) mode.

  • -xml — Causes output to be displayed in XML format for the Oracle Enterprise Manager.

  • -v, -vv, and -vvv — Sets the log level. The -v option is for fine, -vv is for finer, and -vvv is for the finest level.

  • -x — Suppresses the banner.

  • -e command — Runs the specified CellCLI command. CellCLI exits after running the command. For example: 

    $ cellcli -e list cell detail
$ cellcli -e "list celldisk attributes name where name   -
  like '.*cell01'"

Authentication

CellCLI does not have a login parameter or a connect command. CellCLI uses the cell operating system authentication. The directory from which CellCLI is invoked is the default directory for unqualified file access in CellCLI SPOOL and START commands.

Parent topic: Overview of the CellCLI Utility

7.1.2 Understanding Command Syntax and Options for CellCLI

This topic describes the syntax and command options for CellCLI.

CellCLI syntax is as follows: 

{admin-command | object-command object} [options] ;

In the preceding syntax, the following arguments are used:

  • admin-command is an administrative action.

  • object-command is an action performed on an object.

  • object is an object or target on which a command performs an action.

  • options extend the use of a command combination to include additional parameters for the command.

When using the CellCLI utility, the following rules apply:

  • Commands, objects, and options are not case-sensitive except where explicitly stated, such as in string patterns used in filtering strings with the LIKE operator.

  • Use single quotation marks or double quotation marks around the name of an object that includes spaces or punctuation. The use of quotation marks should match. For example, "this is incorrect' is incorrect because the first mark is double quotation marks, and the second is a single quotation mark.

  • The current, local cell is the cell to which all CellCLI commands apply.

  • A semicolon (;) is optional at the end of a CellCLI command.

  • A hyphen (-) is used at the end of a line to continue a long command onto the next line. If you are using hyphens in names or to denote negative values, it must be immediately followed by an alphanumerical value.

Parent topic: Overview of the CellCLI Utility

7.1.3 Reserved Words

If any of the reserved keywords are used as values in commands, then they must be enclosed in quotation marks.

The following are CellCLI reserved words: 

ABORT
ACTIVE
ACTIVEREQUEST
ALERTDEFINITION
ALERTHISTORY
ALL
ALTER
ASSIGN
BBU
BMC
CALIBRATE
CATPLAN
CELL
CONFIGUREBMC
CREATE
DBPLAN
DESCRIBE
DETAIL
DROP
EXPORT
FLASHCACHE
FLASHCACHECONTENT
FOR REPLACEMENT
FORCE
GRIDDISK
IGNORE REDUNDANCY
IMPORT
INACTIVE
IORMPLAN
KEY
LED
LIST
LUN
MAIL
MEMORY
METRICDEFINITION
METRICCURRENT
METRICHISTORY
MS
NULL
OFF
ON
PHYSICALDISK
PRIVILEGE
REALM
RESTART
RS
RULE
SHUTDOWN
SNMP
STARTUP
THRESHOLD
USER
VALIDATE

Parent topic: Overview of the CellCLI Utility

7.1.4 CellCLI Command-Line Editing

Most of the command editing features of CellCLI are similar to modern shells, such as bash and tcsh.

The CellCLI utility supports command-line history and editing, similar to Berkeley Software Distribution (BSD) editline and GNU readline functionality.

Parent topic: Overview of the CellCLI Utility

7.1.5 CellCLI Input and Output Options

Oracle Exadata System Software command-line utilities read commands from standard input and write output to standard output.

You can use the host operating system options for redirecting input and output to compose and process command scripts. For example, you can perform the following redirection:

$ CellCLI < command-script-in  > results-out

In this example, the output from CellCLI commands in the command-script-in file are written to the results-out file.

Parent topic: Overview of the CellCLI Utility

7.1.6 Comments in CellCLI Scripts

You can add single-line comments to CellCLI scripts using multiple formats.

You can begin the comment line with REMARK,REM or -- (two hyphens).

For example, the following are valid syntax for comments:

REMARK This is a comment
REM This is a comment
-- This is a comment

Parent topic: Overview of the CellCLI Utility

7.1.7 Line Continuation in CellCLI Commands

To continue a long command on to the next line, insert a hyphen (-) at the end of the line.

After inserting the hyphen, press Enter, and continue typing the command.

For example:

CellCLI> LIST CELLDISK WHERE name LIKE 'CD_04.*' -
         ATTRIBUTES name, status, comment

Parent topic: Overview of the CellCLI Utility

7.2 About CellCLI Administration Commands

CellCLI administrative commands do not act directly on objects.

The following administration commands are available with CellCLI:

Note:

The celladmin user should be used to run all services on the cell.The cellmonitor user is for monitoring purposes. The cellmonitor user can run the following commands:

  • DESCRIBE

  • EXIT

  • HELP

  • LIST

  • REMARK

  • SET

  • START

Parent topic: Using the CellCLI Utility

7.3 About CellCLI Object Commands

This topic describes the CellCLI object commands, object types, and object attributes.

The following CellCLI commands operate on Oracle Exadata System Software objects:

Parent topic: Using the CellCLI Utility

7.4 About CellCLI Object Types

There are several Oracle Exadata System Software object types that can be used with CellCLI object commands.

  • ACTIVEREQUEST — An active request provides a client-centric or application-centric view of client I/O requests that are currently being processed by a cell. The active request object can be used only with the LIST command.

  • ALERTDEFINITION — An alert definition provides a definition for every alert that can be produced on the cell. Alerts are defined on metrics and other sources of alerts.

  • ALERTHISTORY — An alert history provides a list of alerts that have occurred on the cell.

  • CELL — Cell refers to the current or local cell. A cell is the server to which disks are attached and on which the CellCLI utility runs.

  • CELLDISK — Each cell disk is associated with a logical unit number (LUN). One physical disk is associated with each cell disk.

  • CLUSTER — An Oracle Grid Infrastructure (GI) cluster, which may contain various Oracle databases.

  • DATABASE — Database refers to an active database instance.

  • DIAGPACK — A diagpack represents a compressed file under $LOG_HOME and contains log files and trace files.

  • FLASHCACHE — Flash storage allocated to Exadata Smart Flash Cache.

  • FLASHCACHECONTENT — List of all objects currently cached in Exadata Smart Flash Cache.

  • FLASHLOG — The portion of flash storage allocated for storing the Exadata Smart Flash Log.

  • GRIDDISK — A grid disk is a logical partition of a cell disk. It is exposed on the Oracle Exadata Storage Server network to the database hosts, where it can be consumed by Oracle ASM as part of a disk group.

  • IBPORT — The InfiniBand Network Fabric ports for Oracle Exadata Storage Server. Does not apply to Oracle Exadata X8M systems.

  • IORMPLAN — An I/O Resource Management (IORM) interdatabase plan is a set of directives that determines allocation of I/O resources to database clients. There is one plan for the cell.

  • IORMPROFILE — IORM interdatabase plans support profiles to ease management, and configuration of interdatabase plans for hundreds of databases. Profiles introduce a way to allocate I/O resources for a database.

  • KEY — A key is a unique hexadecimal string that identifies clients for security purposes.

  • LUN — Logical unit number (LUN) is the address for an individual physical disk device (a single-disk LUN). LUNs are automatically discovered when the cell is started. They are assigned to the corresponding cell disk when the cell disk is first created or when cell disks are discovered after the system is restarted. LUNs that are not yet assigned to a cell disk have a NULL value for the cellDisk attribute.

  • METRICCURRENT — Describes the most recent (most current) metric observation.

  • METRICDEFINITION — Describes the configuration of a metric.

  • METRICHISTORY — Describes the collection of past (historical) metric observations.

  • METRICSTREAM — Describes the set of metrics configured for fine-grained collection and real-time insight.

  • OFFLOADGROUP — An object that contains modifiable attributes of offload groups, and can be used to restart, start up, and shut down services.

  • OFFLOADPACKAGE — An object that contains attributes describing offload support on the cell, including the installation time.

  • PHYSICALDISK — A disk is called a physical disk on the cell. Physical disks can be listed, but they are not managed directly by CellCLI. Physical disks are automatically discovered and assigned to the corresponding cell disk when the cell disk is first created or when cell disks are discovered after the system is restarted.

  • PLUGGABLEDATABASE — This object describes tenant databases known to the cell.

  • PMEMCACHE — The portion of persistent memory (PMEM) storage allocated for use as a cache.

    Note:

    Oracle Exadata System Software release 23.1.0 introduces Exadata RDMA Memory (XRMEM). XRMEM represents the collection of Exadata software technologies that provide direct access to storage server memory using Remote Direct Memory Access (RDMA), enabling faster response times and lower read latencies. In this release, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

  • PMEMLOG — The portion of persistent memory (PMEM) storage allocated for caching redo log data.

    Note:

    Oracle Exadata System Software release 23.1.0 introduces Exadata RDMA Memory (XRMEM). XRMEM represents the collection of Exadata software technologies that provide direct access to storage server memory using Remote Direct Memory Access (RDMA), enabling faster response times and lower read latencies. In this release, the persistent memory commit accelerator, previously known as PMEM log, is now called XRMEM log.

  • PRIVILEGE — A right or permission assigned to a role.

  • QUARANTINE — A quarantine stops faulty SQL statements from performing a Smart Scan. This reduces software crashes, and improves storage availability.

  • ROLE — A named group of related privileges.

  • SOFTWAREHISTORY — A list of final states for past software updates.

  • SOFTWAREUPDATE — An object that contains the software location and time parameters for scheduling software updates

  • THRESHOLD — A threshold describes the rules for generating stateful alerts based on a specific metric. The rules include boundary (threshold) values and how long the metric values can violate these boundaries before an alert is generated.

  • USER — A person allowed access to the storage servers.

  • XRMEMCACHE — Memory allocated for use as the Exadata RDMA Memory Cache (XRMEM cache).

    Note:

    Oracle Exadata System Software release 23.1.0 introduces Exadata RDMA Memory (XRMEM). XRMEM represents the collection of Exadata software technologies that provide direct access to storage server memory using Remote Direct Memory Access (RDMA), enabling faster response times and lower read latencies.

  • XRMEMLOG — The portion of persistent memory (PMEM) storage allocated for caching redo log data.

    Note:

    Oracle Exadata System Software release 23.1.0 introduces Exadata RDMA Memory (XRMEM). XRMEM represents the collection of Exadata software technologies that provide direct access to storage server memory using Remote Direct Memory Access (RDMA), enabling faster response times and lower read latencies. In this release, the persistent memory commit accelerator, previously known as PMEM log, is now called XRMEM log.

Not all possible command-object combinations are valid. For valid command-object combinations, review the syntax for the specific object command.

Related Topics

Parent topic: Using the CellCLI Utility

7.5 About Quoting Object Names

If an object name has characters that cause parsing errors enclose the object name in quotes.

The object name can be a number or string in commands that have the following format:

<verb> <object_type> <object_name>

For example, consider the following command:

CellCLI> list pluggabledatabase  CDB$ROOT
                                     ^
CELL-01504: Invalid command syntax.

LIST is the verb, PLUGGABLEDATABASE is the object type, and CDB$ROOT is the object name. In the above example, the parser throws an error when confronted by the $ character in the object name.

For object names that contain invalid characters, you need to surround the object name with either single or double quotes to force the parser to treat the object name as a string.

To avoid this error, surround the object name with either single or double quotes:

CellCLI> LIST PLUGGABLEDATABASE 'CDB$ROOT' 
         CDB$ROOT

Parent topic: Using the CellCLI Utility

7.6 About CellCLI Object Attributes

Each CellCLI object has a set of attributes that are assigned when the object is created or altered.

Attribute filters and lists are used to specify which attributes and objects are displayed in the output of the LIST command.

All attributes can be displayed, but only some can be modified directly by the user. To display a list of attributes and determine which ones can be modified, use the DESCRIBE command.

Related Topics

Parent topic: Using the CellCLI Utility

7.6.1 Restrictions on Values of Common Attributes

Review the following restrictions for the values of attributes used by multiple CellCLI objects.

  • The value of the name attribute must be less than 256 characters and composed only of the following ASCII characters:

    • Lowercase alphabetic characters (a to z)
    • Uppercase alphabetic characters (A to Z)
    • Numbers (0 to 9)
    • Underscore (_)
    • Hyphen (-)

      Note:

      On Oracle Exadata System Software release 19.2.0, or earlier, you must enclose the string in double quotes. For example: "hyphenated-string"

  • The value of the comment attribute must be less than 256 characters.

See the syntax of each CellCLI command for any additional restrictions on attribute values.

Parent topic: About CellCLI Object Attributes

7.6.2 Attribute Lists in LIST Command

You can specify which attributes to display for the LIST command with the optional ATTRIBUTES clause.

This syntax of the ATTRIBUTES clause is: 

ATTRIBUTES { ALL | attribute1 [, attribute2] ... }

ALL displays all possible object attributes for the LIST object.

Example 7-1 Listing METRICHISTORY for Specific Attributes

This example shows the LIST METRICHISTORY command with the name and metrictype attributes specified, and the output. 

LIST METRICHISTORY ATTRIBUTES name, metrictype
         CL_CPUT           Instantaneous
         CL_FANS           Instantaneous
         CL_RUNQ           Instantaneous
         CL_TEMP           Instantaneous
         N_NIC_RCV_SEC     Rate
         N_NIC_TRANS_SEC   Rate
...

Parent topic: About CellCLI Object Attributes

7.6.3 Attribute Filters in LIST and ALTER Commands

You can use the attribute_filters clause to specify the objects to display in LIST commands. Some ALTER commands also support the attribute_filters clause.

This syntax of the attribute_filters clause is: 

WHERE attribute_filter1 [ AND attribute_filter2 ... ]

Each attribute_filterN has the following syntax: 

attribute [ NOT | ! ] operator comparison_value

The attribute placeholder represents the name of the attribute to use for filtering. The supported types of operator are listed in the following table. These operators can be combined with NOT or !.

Table 7-1 Supported Operators in Attribute Filters

Operator Description

=

Tests for equality between string, status, or numeric attributes. For example:

status NOT = normal

>

Tests for values greater than the numeric attributes. For example:

size > 139920M

<

Tests for values less than the numeric attributes. For example:

freeSpace !< 100M

LIKE

Tests for a regular expression match with a string attribute using case-sensitive matching. For example:

LIKE 'GD_IO_RQ.*'

When used with the supported operators, comparison_value is one of the following data types:

  • Numeric
  • Literal: Value such as active or normal
  • Datetime: Time value supported only for ALERTHISTORY
  • String: Value delimited by single quotation marks ('') or double quotation marks (" ")
  • NULL: Unassigned strings or empty lists

Parent topic: About CellCLI Object Attributes

7.7 CellCLI Command Reference

CellCLI has both administrative and object commands.

The following commands are available with the CellCLI utility:

Parent topic: Using the CellCLI Utility

7.7.1 ALTER

Purpose

The ALTER command performs an action on or changes attributes of a single cell object or multiple Oracle Exadata System Software objects. The ALTER command can be used to change an attribute or to take an action upon the object.

Syntax

ALTER { object_type object_name [, object_name]... operation
      | attribute_name = attribute_value 
        [, attribute_name = attribute_value]...
     }

Usage Notes

When multiple objects are the target of an ALTER command, there is the possibility of partial success. If an error occurs, then the command is interrupted, and the remaining objects are not changed.

Related Topics

Parent topic: CellCLI Command Reference

7.7.1.1 ALTER ALERTHISTORY

Purpose

The ALTER ALERTHISTORY command changes the attributes of all or specified alert histories.

Syntax

ALTER ALERTHISTORY { ALL | alertid1  [,alertid2 ...]}
       examinedBy=user_name

Usage Notes

The following arguments can be used with the command:

  • alertidn: The identifier of the alerts to be changed.

  • user_name: The name of the user who acknowledged the alert.

Example 7-2 Altering ALERTHISTORY Attributes

This example shows the ALTER command used with the ALERTHISTORY object to update the examinedBy attribute. The examinedBy attribute is the only ALERTHISTORY attribute that can be modified. 

CellCLI> ALTER ALERTHISTORY 1671443714 -
                            examinedBy="jdoe"

CellCLI> ALTER ALERTHISTORY ALL examinedBy="jdoe"

Parent topic: ALTER

7.7.1.2 ALTER CELL

Purpose

The ALTER CELL command changes the attributes of the cell.

Syntax

ALTER CELL  {
  | SHUTDOWN SERVICES { RS | MS | CELLSRV | ALL } [IGNORE REDUNDANCY]
  | RESTART SERVICES  { RS | MS | CELLSRV | ALL } [IGNORE REDUNDANCY]
  | RESTART BMC
  | STARTUP SERVICES  { RS | MS | CELLSRV | ALL }
  | LED {ON | OFF}
  | DONOTSERVICELED {ON | OFF [FORCE]}
  | VALIDATE { MAIL | SNMP | CONFIGURATION }
  | VALIDATE SYSLOGCONF selector.node
  | CONFIGUREBMC
  | BBU { DROP FOR REPLACEMENT | REENABLE }
  | attribute_name = attribute_value 
        [, attribute_name = attribute_value]...
  }
7.7.1.2.1 ALTER CELL Commands for Managing Services

Syntax

ALTER CELL {
    SHUTDOWN SERVICES { RS | MS | CELLSRV | ALL } [IGNORE REDUNDANCY]
  | RESTART SERVICES  { RS | MS | CELLSRV | ALL } [IGNORE REDUNDANCY]
  | STARTUP SERVICES  { RS | MS | CELLSRV | ALL }
}

Usage Notes

The following table lists the arguments and options for the ALTER CELL commands that perform service management operations:

Argument Description

SHUTDOWN SERVICES {RS | MS}

Shuts down the Restart Server or Management Server service.

SHUTDOWN SERVICES CELLSRV [IGNORE REDUNDANCY]

Shuts down the Cell Server service.

If you include IGNORE REDUNDANCY, then the service is immediately stopped without waiting on the redundancy checks from Oracle ASM.

SHUTDOWN SERVICES ALL

Shuts down all services (Restart Server, Management Server, and Cell Server).

If you include IGNORE REDUNDANCY, then the Cell Server service is immediately stopped without waiting on the redundancy checks from Oracle ASM.

RESTART SERVICES {RS | MS}

Stops and then starts the Restart Server or Management Server service.

RESTART SERVICES CELLSRV [IGNORE REDUNDANCY]

Stops and then starts the Cell Server service.

If you include IGNORE REDUNDANCY, then the service is stopped without waiting on the redundancy checks from Oracle ASM.

RESTART SERVICES ALL [IGNORE REDUNDANCY]

Stops and then starts all services (Restart Server, Management Server, and Cell Server).

If you include IGNORE REDUNDANCY, then the Cell Server service is stopped without waiting on the redundancy checks from Oracle ASM.

STARTUP SERVICES {RS | MS | CELLSERV | ALL}

Starts the specified service. If you use the keyword ALL, then all services are started.

The following are additional usage notes for the ALTER CELL commands that perform service management:

  • During a shutdown operation affecting CELLSRV, the system first checks the status of the grid disks to ensure that it is safe to proceed. Specifically, the asmDeactivationOutcome attribute is checked for all of the grid disks. If the attribute value is yes, then the grid disk can be deactivated without data loss.

    Depending on the command, the following occurs if the asmDeactivationOutcome attribute value is yes for all of the grid disks:

    • For the ALTER CELL SHUTDOWN SERVICES CELLSRV and ALTER CELL SHUTDOWN SERVICES ALL commands:
      1. The grid disks are deactivated on the cell.
      2. Oracle ASM takes the corresponding ASM disks offline.
      3. Finally, the applicable services are shutdown.

    • For the ALTER CELL RESTART SERVICES CELLSRV and ALTER CELL RESTART SERVICES ALL commands, the CELLSRV service is restarted immediately, followed by a restart of the MS and RS services, if applicable.

    Otherwise, if the asmDeactivationOutcome attribute value is not yes for any grid disk, then the CELL-01548 error message is displayed and the status of the services remains unchanged.

  • The IGNORE REDUNDANCY option bypasses the asmDeactivationOutcome attribute checks. Using the IGNORE REDUNDANCY option results in immediate execution of the command. Consequently, if the command shuts down the only online copy of a grid disk, then the corresponding Oracle ASM disk group is dismounted.

  • If the Restart Server (RS) service is not running, then you must run either ALTER CELL STARTUP SERVICES RS or ALTER CELL RESTART SERVICES RS before you can start other services individually, or you can run the ALTER CELL STARTUP ALL command.

Example 7-3 Starting Up and Shutting Down Cell Services

This example shows how to start up and shut down cell services.

CellCLI> ALTER CELL STARTUP SERVICES CELLSRV
CellCLI> ALTER CELL STARTUP SERVICES ALL

CellCLI> ALTER CELL SHUTDOWN SERVICES MS
CellCLI> ALTER CELL SHUTDOWN SERVICES CELLSRV IGNORE REDUNDANCY
CellCLI> ALTER CELL SHUTDOWN SERVICES ALL 

CellCLI> ALTER CELL RESTART SERVICES ALL IGNORE REDUNDANCY

Parent topic: ALTER CELL

7.7.1.2.2 ALTER CELL Commands for Managing Exadata Storage Server Hardware

Syntax

ALTER CELL {
    RESTART BMC
  | LED {ON | OFF}
  | DONOTSERVICELED {ON | OFF [FORCE]}
  | CONFIGUREBMC
  | BBU { DROP FOR REPLACEMENT | REENABLE }
  | attribute_name = attribute_value [, attribute_name = attribute_value]...
  }

Usage Notes

The following table lists the arguments and options for the ALTER CELL commands that perform Exadata storage server hardware management operations:

Argument Options Description

RESTART BMC

none

Restarts the Baseboard Management Controller (BMC).

LED

ON

OFF

LED ON and LED OFF operations turn on and off the Fault-Service Required LED.

You can manually light the LED to indicate that a cell requires maintenance. The LED also turns on automatically if a component fails.

DONOTSERVICELED

ON

OFF

Turns the Do Not Service LED on and off. This LED is available with Oracle Exadata Database Machine X7 and later models.

CONFIGUREBMC

none

Configures the BMC for hardware alerts to the local cell so that Management Server (MS) can pick up the alerts.

BBU

DROP FOR REPLACEMENT

REENABLE

BBU DROP FOR REPLACEMENT drops the hard disk controller battery-backed unit (BBU).

BBU REENABLE re-enables the BBU.

The following are additional usage notes for the ALTER CELL commands that perform storage server hardware management:

  • The ALTER CELL BBU DROP FOR REPLACEMENT command is run prior to replacement of a hard disk controller battery. The command changes the caching policy from writeback to writethrough, and turns on the locator LED. The new battery is enabled automatically.

  • The ALTER CELL BBU REENABLE command is run when a battery is removed and then the same battery is re-inserted. The command changes the caching policy from writethrough to writeback, and turns off the locator LED.

Attributes Related to Hardware Management

  • The bbuLearnCycleTime attribute is used to set the start time for the battery learn cycle. After the learn cycle has completed, the attribute reverts to its default quarterly cycle.

  • The bbuLearnSchedule attribute is used to set the next battery learn cycle. The following parameters are used with the bbuLearnSchedule attribute:

    • month: Values are 1 through 12. The month entered must be within the current month and the next three months. For example, if the bbuLearnSchedule attribute is set in February, then the months could be February, March, April or May.
    • week: Values are 1 through 5. The value 1 represents the first week of the month, 2 represents the second week, and so on. The week value must be specified when specifying month and day.
    • day: Values are 1 through 7. The value 1 represents Sunday, 2 represents Monday, and so on. The day value must be specified when specifying month and week.
    • date: Values are 1 through 31. The values represent the days of the month. The default date is 17.
    • hour: Values are 0 through 23. The value 0 represents 12:00 a.m., 1 represents 1:00 a.m., and so on.
    • minute: Values are 0 to 59. The values represent the minutes in an hour.
    • second: Values are 0 to 59. The values represent the seconds in a minute.

  • The ALTER CELL eighthRack=true command enables or disables an Eighth Rack configuration on Oracle Exadata Database Machine X3-2 Quarter Racks or later. The options are true to enable the Eighth Rack configuration, and false to disable the Eighth Rack configuration. The ALTER CELL eighthRack=true command requires that there are no cell disks because enabling the Eighth Rack configures only half of the hard disks and flash capacity. After using this command you must restart Cell Server (CELLSRV) to make the new changes effective and prevent unexpected results.

Examples

Example 7-4 Setting the Cell LED Off and On

This example shows how to set the Fault-Service Required LED on and off for the cell. 

CellCLI> ALTER CELL LED OFF
CellCLI> ALTER CELL LED ON

Example 7-5 Setting the Battery Learn Cycle

This example shows how to schedule for the battery learn cycle. In this example, the command sets the battery learn cycle to occur January 17 3:00:59, and then the following learn cycles are April 17 3:00:59, July 17 3:00:59, and October 17 3:00:59. The default setting is "MONTH 1 DATE 17 HOUR 2 MINUTE 0."

CellCLI> ALTER CELL bbuLearnSchedule = "MONTH 1 HOUR 3 SECOND 59"

Parent topic: ALTER CELL

7.7.1.2.3 ALTER CELL Commands for Configuration Validation

Syntax

ALTER CELL {
    VALIDATE { MAIL | SNMP | CONFIGURATION }
  | VALIDATE SYSLOGCONF selector.node
  }

Usage Notes

The following table lists the arguments and options for the ALTER CELL commands that perform configuration validation operations:

Argument Description

VALIDATE MAIL

The VALIDATE MAIL operation sends a test message using the e-mail attributes configured for the cell.

VALIDATE SNMP

The VALIDATE SNMP operation sends a test message using the SNMP attributes configured for the cell. The VALIDATE SNMP TYPE=ASR operation validates Oracle ASR on Oracle Exadata Storage Server.

VALIDATE CONFIGURATION

The VALIDATE CONFIGURATION operation validates the configuration. When the validation is complete and correct, the system responds with Cell cell_name successfully altered. If there is a problem, then the system responds with an error message.

VALIDATE SYSLOGCONF facility.priority

The VALIDATE SYSLOGCONF facility.priority sends a test message for the specified facility and priority.

Usage Notes

For more information about SYSLOG configuration, see SYSLOG Attributes.

Examples

Example 7-6 shows how to validate the e-mail setup on a cell.

Example 7-7 shows how to validate the Oracle ASR e-mail setup on a cell.

Example 7-8 shows how to validate the SNMP setup on a cell.

Example 7-9 shows how to validate the configuration on a cell.

Example 7-10 shows a sample error message when configuration on a cell is incorrect.

Example 7-6 Validating E-mail on a Cell

CellCLI> ALTER CELL VALIDATE MAIL

Example 7-7 Validating Oracle ASR E-mail on a Cell 

CellCLI> ALTER CELL VALIDATE SNMP type=asr

Example 7-8 Validating SNMP on a Cell

CellCLI> ALTER CELL VALIDATE SNMP

Example 7-9 Validating Configuration on a Cell

CellCLI> ALTER CELL VALIDATE CONFIGURATION

Cell CD_01_cell01 successfully altered

Example 7-10 Checking an Incorrect Configuration on a Cell

CellCLI> ALTER CELL VALIDATE CONFIGURATION

CELL-02827: Cell configuration check for hardware and firmware encountered the
following issues:

ILOM check has detected the following issue(s):
    Attribute Name : ILOMVersion
    Required       : 3.0.6.10.a r49240
    Found          : 3.0.6.10.a r49385

Parent topic: ALTER CELL

7.7.1.2.4 ALTER CELL Commands for Setting Attributes

Syntax

ALTER CELL
    attribute_name = attribute_value 
        [, attribute_name = attribute_value]...

Usage Notes

The attributes that can be changed using the ALTER CELL command are shown as modifiable in Example 7-97 or described below.

7.7.1.2.4.1 Caching Attributes

Flash Cache Attributes

The flashCacheMode attribute is used to display and set the current value for flash cache. The values are writethrough (the default) or writeback. Note the following about the flashCacheMode attribute:

  • If the attribute is modified from writeback to writethrough and there is existing flash cache, then an error is displayed. The flash cache must be flushed and dropped before changing the attribute to writethrough.

  • If the attribute is to be modified from writethrough to writeback, then flash cache must be dropped before modifying the attribute.

  • Write back caching can be disabled on the grid disks that do not need caching, such as the grid disks in the RECO disk group. This allows other objects to use the cache space.

    See Also:

Flash cache compression is available in Oracle Exadata System Software releases 11.2.3.3.0 and later running on only Oracle Exadata Database Machine X3 and X4 storage servers.

The ALTER CELL flashCacheCompress command enables or disables flash cache compression. The options are true to enable flash cache compression, and false to disable flash cache compression. To enable flash cache compression on Oracle Exadata Database Machine X3 and X4 storage servers, use the following command: 

CellCLI> ALTER CELL flashCacheCompress=true

Note:

Oracle Advanced Compression Option is required to enable flash cache compression.

See Also:

Oracle Exadata Database Machine Maintenance Guide for additional information about enabling flash cache compression

Flash cache compression must be disabled before a storage server is downgraded to an earlier release.

RAM Cache Attributes

The ramCacheMode attribute can be set to on, off, or auto. The default value is auto, which means the RAM Cache feature is not enabled. When you modify this attribute, you must restart CELLSRV for the change to take effect.

Note:

Commencing with the September 2022 Oracle Exadata System Software release updates (versions 22.1.3, 21.2.16, and later), the storage server RAM Cache feature is deprecated.

Examples

Example 7-11 shows how to set the flash cache mode.

Example 7-12 shows how to enable flash cache compression on a cell in Oracle Exadata Database Machine X4-2.

Example 7-11 Setting the Mode for Flash Cache

CellCLI> ALTER CELL flashcachemode = writeback

Example 7-12 Enabling Flash Cache Compression

This example shows how to enable flash cache compression for a storage server.

CellCLI> ALTER CELL flashCacheCompress=true
7.7.1.2.4.2 Alert Notification Attributes

Configuring Alert Notifications

To set up the cell to send notifications about alerts, you can configure the following cell attributes:

  • mailServer: Fully qualified domain name of the email relay server used to send alert notifications. This attribute only requires specification in cases where DNS returns an unreachable or invalid mail exchange (MX) record for the email server specified in smtpToAddr.
  • smtpPort: Email server port used to send alert notifications
  • smtpUseSSL: Specification to use Secure Socket Layer (SSL) encryption for alert notifications.
  • smtpFrom: User name that appears in the From: header of the alert notifications
  • smtpFromAddr: Email address that appears in the From: header of the alert notifications. This email address is not authenticated with the email server.
  • smtpToAddr: Address to which email is sent. It can be a comma-delimited list in quotation marks to allow multiple subscribers to alerts.
  • snmpSubscriber: List of hosts that subscribe to the SNMP alert notifications
  • snmpUser: Defines the user who receives SNMP alerts
  • snmpEngineID: An identifier used by the SNMP managers to subscribe to alerts from the storage cells
  • notificationMethod: Notification method for alerts
  • notificationPolicy: Indicator for severity alerts to be sent to subscribers
  • emailFormat: File format for email messages
  • emailSubscriber: List of names that subscribe to the alert notifications

Usage Notes

  • mailServer

    The mailServer attribute identifies the email relay server used to send alert notifications. When you modify the mailServer attribute value, the Exadata Management Server (MS) automatically configures and restarts the sendmail service. You can clear the mailServer attribute and remove the email relay server from the sendmail configuration by setting mailServer to an empty string enclosed by quotation marks (mailServer='').

  • smtpPort

    The smtpPort attribute can be reset to the default value by setting it to an empty string enclosed by quotation marks (smtpPort='').

  • smtpUseSSL

    The smtpUseSSL attribute enables Secure Socket Layer (SSL) encryption on the email notifications when the attribute is set to true.

  • smtpToAddr

    The smtpToAddr attribute can be used to set a list of comma-delimited email addresses that are the recipients of the alert notification. The list must be enclosed in quotation marks.

  • snmpSubscriber

    The snmpSubscriber attribute can be set to a list of SNMP targets to which the SNMP alert notification is sent. The targets are specified as follows: 

    snmpSubscriber[-|+]=(
  (host=host[,port=port][,community=community][,type=user_type][,fromIP="ip"][,asrmPort="ASRManager_port"])
[,(host=host[,port=port][,community=community][,type=user_type][,fromIP="ip"][,asrmPort="ASRManager_port"])] ...)

    The smnpSubscriber attribute uses the following values:

    • The host must be specified as either a host name or an IP address. Enclose the host name or IP address in quotation marks if it contains non-alphanumeric characters.

    • The default value for port is 162. This value is optional.

    • The default value for community is public. This value is optional.

    • The snmpSubscriber types are ASR, v3, and v3ASR. Specifying a type value is optional.

      • The default value for type is NULL.

      • The type=asr option sets the Oracle ASR destination for Oracle Exadata Storage Server, and its ILOM. Removing all snmpSubscriber entries with type=asr from the SNMP subscriber list disables the trap mechanism for Oracle Exadata Storage Server and its ILOM.

      • The snmpSubscriber with type=asr or type=v3ASR should only be configured to point to Oracle ASR Manager.

      • For types v3 and v3ASR, a snmpUser must be defined, and the user name is provided instead of community.

      • For the v3ASR type, the user must be defined with authProtocol = SHA, and privProtocol = AES. These are the only protocols supported by Oracle ASR Manager. Setting the snmpSubscriber as type v3ASR also sets the ILOM properties and rules for traps sent by ILOM.

      • If type is not specified, then the default is version 1, cell_alert traps. There is no string to specify this type. To use this type, just omit the type field.

    • The fromIP field enables you to specify an IP address from which the trap is sent. If this field is not specified, it defaults to the IP address associated with eth0. Use this field if the default IP address is not registered with Oracle ASR Manager. Oracle ASR Manager only processes SNMP traps that are sent from IP addresses that it recognizes.

      The fromIP field is allowed only for SNMP subscribers whose type is either ASR or v3ASR.

      For example:

      CellCLI> alter cell snmpSubscriber=((host=asrhost,port=162,community=public,fromIP="1.1.1.1",type=ASR))

      The following example returns an error because the type is not ASR or v3ASR. 

      CellCLI> alter cell snmpSubscriber=((host=localhost,port=162,community=public,fromIP="1.1.1.1"))
CELL-00068: The fromIP field is only supported for ASR SNMP subscribers.

    • The asrmPort field enables you to specify the port number on an Oracle ASR Manager machine that MS uses to communicate with Oracle ASR Manager. This port must be the same as the HTTP port of Oracle ASR Manager’s HTTP Receiver. You can check this by running asr show_http_receiver on the Oracle ASR Manager machine.

      The asrmPort field is allowed only for SNMP subscribers whose type is either ASR or v3ASR. The default value for this port is 16161.

    By default, ALTER CELL smnpSubscriber=(SNMPtargets) replaces the existing smnpSubscriber value. However, starting with Oracle Exadata System Software release 21.2.0, you can add to the existing list of SNMP targets by using smnpSubscriber+=(SNMPtarget). For example: 

    CellCLI> alter cell snmpSubscriber+=((host=newhost,port=162,community=public))

    Also, starting with Oracle Exadata System Software release 22.1, you can remove an entry from the existing list of SNMP targets by using smnpSubscriber-=(SNMPtarget). For example: 

    CellCLI> alter cell snmpSubscriber-=((host=myhost,port=162,community=public))

    The following message is displayed after setting smnpSubscriber: 

    snmpSubscriber <old_value> has been replaced with <new_value>

    For example:

    snmpSubscriber ((host=hosta)) has been replaced with ((host=hostb))

    After startup of the Management Server (MS), the snmpSubscriber list entries with type=asr are added to the ILOM for the cell. This ensures that when an ILOM is replaced, the entries are set for the new ILOM. If the entries are removed from the ILOM, then they must be manually added to the ILOM using the ALTER CELL ... snmpUser= command.

  • snmpUser

    The snmpUser attribute defines the user who receives SNMP alerts. This command can only be run in interactive mode. There are two methods for configuring this attribute. 

    snmpuser=((user_clause)[,(user_clause)[,..]])

snmpuser.name=(user_clause)

    • If you specify snmpuser, then you must provide a user_clause for every configured user. If you omit a user, then that user will no longer receive SNMP alerts. The ((user_clause)[,(user_clause)[,..]]) string that you provide overwrites the previous string used for the snmpuser attribute.

    • If you specify snmpuser.name, then you must provide a user_clause for only the specified user. This allows you to add, delete, or modify each user individually, without having to supply the entire snmpuser attribute string each time.

    • If you use snmpuser='', then all SNMP users are removed. If you use snmpuser.name='', then only the specified user is removed. You cannot remove an SNMP user while it is still referenced by a V3 SnmpSubscriber.

    Each method uses a user_clause, which has the following format: 

    (([name=user1,] authProtocol=auth_type, authPassword=*,               \
privProtocol=priv_type, privPassword=*) ,                            \
(name=user2, authProtocol=auth_type, authPassword=*,                 \
privProtocol=priv_type, privPassword=*, ), ...)

    If updating a single user, then do not include the phrase name=user1, in the user_clause, because you have already supplied the name as part of snmpuser.name.

    • name is the user name.

    • Only * is allowed for the password values in the command. Passwords are not stored or displayed. Secure hash keys are computed and used for trap authentication and encryption.

    • authProtocol is the authentication protocol. Options are MD5 or SHA.

      The authProtocol must be specified for the snmpUser attribute.

      The system prompts for the authentication password. The authentication password must have 8 to 12 alphanumeric characters.

    • privProtocol is encryption protocol. Options are none, AES, or DES. The default is none when the privProtocol attribute is not specified.

      The system prompts for an encryption password if the encryption protocol is specified. The password is exactly 8 alphanumeric characters, and they are case sensitive.

  • snmpEngineID

    The ALTER CELL snmpEngineID command is used by the SNMP managers to subscribe to alerts from the storage cells. The snmpEngineID parameter can be up to 20 characters. It should be unique for each target within a data center. The default is the cell name. This default is used if the snmpEngineID attribute is not set before the SNMP users are defined.

    Note:

    The engine identifier should not be changed after SNMP users are defined. Any change to an engine identifier causes the user keys to be re-computed, and user passwords must be re-entered.

  • notificationMethod

    The notificationMethod attribute value can be mail, snmp, none, or a combination of mail and snmp, such as notificationMethod='mail,snmp'. The default value is mail.

  • notificationPolicy

    The notificationPolicy attribute value can be none or a combination of critical, warning, or clear, such as notificationPolicy='warning,clear.'

    • The critical value refers to hardware-generated alerts or alerts generated by Automatic Diagnostic Repository (ADR) or BMC. The critical value also refers to a metric alert when the value exceeds the critical threshold specified in the metric definition.
    • The warning value refers to a metric alert when the value exceeds the warning threshold specified in the metric definition.
    • The clear value refers to a metric alert when the value is below the threshold boundary after having previously exceeded a warning or critical threshold.
    • The maintenance value refers to all hardware-related errors. The hardware errors are reported as "Maintenance" in email message subject lines.

  • emailFormat

    The emailFormat attribute can be html or text. By default, email notifications are sent in HTML format. Change the value to text to receive plain text email notifications.

  • emailSubscriber

    The ALTER CELL emailSubscriber command sets a list of comma-delimited email addresses that are the recipients of alert notifications for specific alert types. The syntax for this command is: 

    ALTER CELL emailSubscriber = ((email="email_address1",                \ 
           alertType="alert_type")                               \
          [, (email="email_address2",alertType="alert_type"), ...])

    • The email address must be a valid email address. The email parameter is mandatory.

    • The alertType parameter specifies the type of alert, and is optional. The alert types are HARDWARE, SOFTWARE, METRIC or ADR. If the alert type is not specified, then the subscription is for all alert types.

    • An empty input string removes the current set of subscribers.

    • The notification policy must be set before alert notifications can be received. The policy applies to all email subscribers. The notification policy for these alerts are the same as for snmpSubscriber alerts.

    To validate that email messages are successfully sent for cell alerts or events, use the ALTER command with the VALIDATE MAIL option. The validation process sends a test email message to the configured recipient. If that test email message is not received, then an email configuration setting is not valid.

Examples

Example 7-13 shows how to set the asrmPort field for an snmpSubscriber.

Example 7-14 shows how to set up email notifications for the cell.

Example 7-15 shows how to specify the type of email alerts. In the example, one subscriber gets hardware and software alerts, and the other subscriber gets ADR alerts.

Example 7-16 shows how to change the format of email messages.

Example 7-17 shows how to modify the SNMP user.

Example 7-18 shows how to modify a single SNMP user.

Example 7-19 shows how to unsubscribe from email alerts.

Example 7-20 shows how to reset the notificationPolicy attribute to its default value.

Example 7-13 Setting the asrmPort for an snmpSubscriber

CellCLI> ALTER CELL snmpSubscriber=((host=host1,port=162,community=public,type=asr,asrmPort=16161))

Example 7-14 Configuring Email Notifications for a Cell

CellCLI> ALTER CELL mailServer='my_mail_relay.example.com',      -
                    smtpFromAddr='john.doe@example.com',         -
                    smtpFrom='John Doe',                         -
                    smtpToAddr='jane.smith@example.com',         -
                    snmpSubscriber=((host=host1),(host=host2)),  -
                    notificationPolicy='clear',                  -
                    notificationMethod='mail,snmp'

Example 7-15 Specifying the Type of Email Alert

ALTER CELL emailSubscriber=                                             \
           ((email="email1@example.com",alertType="HARDWARE,SOFTWARE"), \
           (email="email2@example.com",alertType="ADR"))

Example 7-16 Changing the Format of Email Messages

CellCLI> ALTER CELL emailFormat='text'
CellCLI> ALTER CELL emailFormat='html'

Example 7-17 Modifying the SNMP User

This example shows the initial configuration of a single SNMP user, where the administrator is prompted to enter the passwords.

CellCLI> ALTER CELL snmpuser = ((name=ASR, authprotocol=md5, authpassword=*,   \
                    privprotocol=AES, privpassword=*))
snmpUser ASR authpassword: password
Confirm snmpUser ASR authpassword: password
snmpUser ASR privpassword: password
Confirm snmpUser ASR privpassword: password

Example 7-18 Modifying a Single SNMP User

The following code examples show adding an SNMP user, changing that user's password, and then removing that user.

## adding users individually
CellCLI> ALTER CELL snmpuser.user2=(authprotocol=SHA,authpassword=*)

snmpUser user2 authpassword: password
Confirm snmpUser user2 authpassword: password

snmpUser ((name=user1, authProtocol=SHA, privProtocol=AES)) has been replaced with 
((name=user1, authProtocol=SHA, privProtocol=AES),(name=user2, authProtocol=SHA)).
Cell cel01 successfully altered

## changing a password of an existing user
CellCLI> ALTER CELL snmpuser.user2 = (authprotocol=SHA,authpassword=password)

Cell cel01 successfully altered

## delete a user individually
CellCLI> ALTER CELL snmpuser.user2=''

snmpUser ((name=user1, authProtocol=SHA, privProtocol=AES),(name=user2, authProtocol=SHA)) has
 been replaced with ((name=user1, authProtocol=SHA, privProtocol=AES)).
Cell cel01 successfully altered

Example 7-19 Unsubscribing from Email Alerts

ALTER CELL emailSubscriber=""

Example 7-20 Setting the Default Value for the notificationPolicy Attribute

This example shows how to set the default value for the notificationPolicy attribute. 

CellCLI> alter cell notificationPolicy=""
7.7.1.2.4.3 Alert Summary Attributes

Configuring Alert Summaries

  • The alertSummaryInterval attribute sets the frequency of the open alerts summary e-mail message. The open alerts e-mail message is an HTML document that provides a concise summary of all open issues on a cell even without access to the cell. Valid options are daily, weekly, biweekly and none.The default value is weekly.

  • The alertSummaryStartTime attribute sets the delivery time for the open alerts summary e-mail message. The command accepts any valid time stamp.

Example 7-21 Setting the Frequency for the Open Alerts Summary E-mail Message

This example shows how to set the frequency for the open alerts summary e-mail message to weekly.

CellCLI> ALTER CELL alertSummaryInterval=weekly

Example 7-22 Setting the Time for Open Alerts Message Delivery

This example shows how to set the delivery time for the open alerts summary e-mail message.

CellCLI> ALTER CELL alertSummaryStartTime="2013-04-23T12:57:00-06:00"
7.7.1.2.4.4 SYSLOG Attributes

Configuring SYSLOG Attributes: syslogconf and syslogFormat

The syslogconf attribute extends syslog rules for a cell. The attribute can be used to designate that syslog messages be forwarded to a specified management server. On the management server, the forwarded messages are directed to a file, console, or management application, depending on the syslog configuration on the management server. The syntax for configuring this attribute is: 

syslogconf = ('selector @node' [, 'selector @node']... )

In the preceding syntax, selector is the message type, and node is the specified server. Both variables follow syslog.conf standard syntax rules.

  • The facility option for the syslogconf attribute must be one of the following: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7, none, and *.

  • The priority option for the syslogconf attribute must be one of the following: alert, crit, debug, emerg, err, error, info, notice, panic, warn, warning, none, and * (asterisk).

The ALTER CELL VALIDATE syslogconf selector command sends a test log message. The test message is directed as specified by rules in the /etc/syslog.conf file. If the syslogconf assignment extends the syslog rules, then a test message is forwarded to the specified management servers.

Starting with Oracle Exadata System Software release 19.1.0, you can use the syslogFormat attribute to change the standard format for syslog to any format by setting the value to the desired format string. Setting the syslogFormat attribute to an empty string removes the format change, reverting the syslog format to the default format. If the format string contains a control character, it must be preceded by a backslash when entering the command.

See Example 7-26 for examples of the syntax.

Starting with Oracle Exadata System Software release 19.3.0, you can use the syslogFormat attribute to enable sending syslog in an encrypted format. For the complete configuration steps, refer to Encrypting System Log Information.

Example 7-23 Using the syslogconf Attribute

This example shows how to add a rule using the syslogconf attribute.

CellCLI> ALTER CELL syslogconf=('*.err;authpriv.none @loghost', -
         '*.emerg @loghost')

Example 7-24 Adding and Validating a Rule

This example shows how to add and validate a rule with test message.

CellCLI> ALTER CELL syslogconf=('kern.crit @loghost')
CellCLI> ALTER CELL VALIDATE syslogconf   'kern.crit'

Example 7-25 Removing All syslog.conf Rules

This example shows how to remove the syslog.conf rule. 

CellCLI> ALTER CELL syslogconf=''

Example 7-26 Setting the Syslog Format to a Custom String Then Reverting to the Default Format

This example shows how to specify a customized format for syslog.

CellCLI> ALTER CELL syslogformat="%TIMESTAMP:::date-rfc3339% %HOSTNAME%%syslogtag%
%syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\\n"

CellCLI> ALTER CELL syslogformat="%TIMESTAMP% %HOSTNAME% %msg%\\n"

CellCLI> ALTER CELL syslogformat=""

Configuring the ILOM SYSLOG: ilomSyslogClients

Starting with Oracle Exadata System Software release 21.2.0, the ilomSyslogClients attribute specifies the remote destination to forward syslog messages from the Integrated Lights Out Manager (ILOM) service processor (SP).

The ilomSyslogClients attribute accepts a comma-separated list of up to two loghost servers. For each loghost server, you must specify a valid hostname or IP address.

For example:

CellCLI> ALTER CELL ilomSyslogClients="192.0.2.101,192.0.2.201"

Note:

The specified ilomSyslogClients must listen on port 514 to receive the ILOM syslog messages.

7.7.1.2.4.5 Disk Scrubbing Attributes

Configuring Disk Scrubbing Attributes

Disk scrubbing proactively inspects and repairs hard disks. If a bad sector is detected on a hard disk, Oracle Exadata System Software automatically orchestrates the repair using data from another mirror copy.

Disk scrubbing is a long-running operation. The time required to complete a scrubbing operation depends mainly on disk size and workload. As a guide, allow between 1 and 2 hours for each terabyte of disk capacity to scrub an otherwise idle disk.

On an idle system, disk scrubbing can drive disk utilization to 100%. However, Exadata I/O Resource Management (IORM) throttles disk scrubbing so that user workloads are prioritized and should not be affected by disk scrubbing.

The ALTER CELL hardDiskScrubInterval command activates (or deactivates) automatic scrubbing and sets the scrubbing interval. Valid options are daily, weekly, biweekly, and none. Using the none option stops all active disk scrubbing operations and deactivates automatic scrubbing.

The ALTER CELL hardDiskScrubStartTime command sets the start time for the scrubbing schedule. Valid options are a specific date and time or now.

In the alert log, you may see messages such as Begin scrubbing celldisk and Finished scrubbing celldisk. These are expected informational messages, and no action is necessary.

Example 7-27 Setting the Disk Scrubbing Interval to Weekly

This example shows how to activate automatic weekly disk scrubbing.

CellCLI> ALTER CELL hardDiskScrubInterval=weekly

Example 7-28 Setting the Start Time for Proactive Disk Scrubbing

This example shows how to set a specific start time for disk scrubbing.

CellCLI> ALTER CELL hardDiskScrubStartTime='2013-08-07T21:19:22-07:00'
7.7.1.2.4.6 Security Certificate Attributes

Configuring CA-Certified Security Certificate Attributes

To set up CA-certified security certificates on the cell for use with ExaCLI, use the following attributes:

Note:

The following attributes can be used only if you are running the ALTER CELL command from ExaCLI.
  • securityPubKey - Specifies the URL to the public key file.
  • securityPrivKey - Specifies the URL to the private key file.
  • securityPrivKeyPW - Specifies the password to use if the private key file is encrypted.

After you upload the CA-certified security certificate, you must restart MS before the new security certificate is visible. 

CellCLI> ALTER CELL RESTART SERVICES MS

See Also:

Using a CA-Certified Security Certificate in Oracle Exadata Database Machine Maintenance Guide

Example 7-29 Configuring the Security Keys for a Storage Server

This example shows how to configure the security keys for a storage server, including supplying the password after entering the command.

exacli -e 'ALTER CELL securityPubKey="http://www.example.com/security/newkey.crt",  -
                   securityPrivKey="http://www.example.com/security/newkey.key", -
                   securityPrivKeyPW=*'

password=****************
7.7.1.2.4.7 Persistence Attributes

Persistent Columnar Cache

Starting with Oracle Exadata System Software release 21.2.0, the columnarCachePersMode attribute controls the persistent columnar cache feature. The valid attribute setting are:

  • on - Enables the persistent columnar cache feature.

  • off - Disables the persistent columnar cache feature.

  • auto - Oracle Exadata System Software decides whether to enable or disable the persistent columnar cache feature. If the columnarCachePersMode attribute is not set, then the auto setting is implied.

    Starting with Oracle Exadata System Software release 21.2.11, the auto setting enables the persistent columnar cache feature (equivalent to columnarCachePersMode=on). Previously, the auto setting disabled the persistent columnar cache feature (equivalent to columnarCachePersMode=off).

After you alter the columnarCachePersMode attribute, you must restart the cell server to implement the change.

Persistent Storage Index

Starting with Oracle Exadata System Software release 21.2.0, the storageIndexPersMode attribute controls the persistent storage index feature. The valid attribute setting are:

  • on - Enables the persistent storage index feature.

  • off - Disables the persistent storage index feature.

  • auto - Oracle Exadata System Software decides whether to enable or disable the persistent storage index feature. If the storageIndexPersMode attribute is not set, then the auto setting is implied.

    Starting with Oracle Exadata System Software release 21.2.11, the auto setting enables the persistent storage index feature (equivalent to storageIndexPersMode=on). Previously, the auto setting disabled the persistent storage index feature (equivalent to storageIndexPersMode=off).

After you alter the storageIndexPersMode attribute, you must restart the cell server to implement the change.

7.7.1.2.4.8 Real-Time Insight Attributes

Commencing with Oracle Exadata System Software 22.1.0, you can use the real-time insight feature to enable real-time monitoring of your Exadata systems.

Fine-Grained Metric Collection

The metricFGCollIntvlInSec attribute controls fine-grained metric collection.

  • To enable fine-grained metric collection, you must set the collection interval to a value between 1 and 60 seconds.

    For example:

    CellCLI> ALTER CELL metricFGCollIntvlInSec=1

    The metricFGCollIntvlInSec setting is related to the automatic upload frequency specified in the metricStreamIntvlInSec attribute. When automatic metric upload and fine-grained collection are both enabled (metricStreamIntvlInSec>0 and metricFGCollIntvlInSec>0), metricStreamIntvlInSec must be between 5 and 30 times metricFGCollIntvlInSec. For example, if metricStreamIntvlInSec=60, then metricFGCollIntvlInSec must be between 2 and 12.

  • To disable fine-grained metric collection on a server, set metricFGCollIntvlInSec=0.

    For example:

    CellCLI> ALTER CELL metricFGCollIntvlInSec=0

    Fine-grained metric collection can be disabled only when automatic metric upload is disabled (metricStreamIntvlInSec=0) or the automatic upload frequency is between 5 and 30 minutes (metricStreamIntvlInSec is between 300 and 1800).

Automatic Metric Upload

The metricStreamIntvlInSec attribute sets the upload interval (in seconds) for automatic uploads to the metric streaming endpoints specified by the metricStreamEndPoint attribute.

  • To enable automatic metric uploads, set the metricStreamIntvlInSec attribute to a non-zero value.

    For example:

    CellCLI> ALTER CELL metricStreamIntvlInSec=25

    The metricStreamIntvlInSec setting is related to the fine-grained collection frequency specified in the metricFGCollIntvlInSec attribute:

    • When automatic metric upload and fine-grained collection are both enabled (metricStreamIntvlInSec>0 and metricFGCollIntvlInSec>0), metricStreamIntvlInSec must be between 5 and 30 times metricFGCollIntvlInSec. For example, if metricFGCollIntvlInSec is set to 5, then metricStreamIntvlInSec must be between 25 and 150.

    • When automatic metric upload is enabled and fine-grained collection is disabled (metricStreamIntvlInSec>0 and metricFGCollIntvlInSec=0), the automatic upload frequency must be between 5 and 30 minutes (metricStreamIntvlInSec must be between 300 and 1800).

  • To disable automatic metric uploads, set metricStreamIntvlInSec=0.

    For example:

    CellCLI> ALTER CELL metricStreamIntvlInSec=0

Metric Upload Endpoints

The metricStreamEndPoint attribute specifies one or more collection endpoints that automatically receive the metric stream. You can set metricStreamEndPoint as follows: 

metricStreamEndPoint[+]=((host="endpoint-URL"[,type="stream-format"][,token="authentication-token"][,{httpProxy|httpsProxy}="proxy-server"])
                          [,(host="endpoint-URL"[,type="stream-format"][,token="authentication-token"][,{httpProxy|httpsProxy}="proxy-server"])]...)

In the metricStreamEndPoint definition:

  • host: Specifies the URL for the collection endpoint. The URL can use HTTP or HTTPS.

  • type: Optionally specifies the format of the stream. Supported values are:

    • json: Provides the stream in a JSON format

    • plaintext: Provides the stream in a plain text format

    The default value is json.

  • token: Optionally specifies the authentication token for the collection endpoint. Consult the metric collection platform for details about generating the token.

  • httpProxy or httpsProxy: Optionally specifies a proxy server to facilitate network connectivity to the collection endpoint. A proxy server is required if a firewall resides between the Exadata system and the collection endpoint.

You can use the optional += operator to add collection endpoints to an existing metricStreamEndPoint definition. Otherwise, the = operator overwrites the previous attribute value.

Metric Tags

The metricStreamTags attribute defines a set of metric tags, which are included in every metric observation generated by the server. These tags can help you to organize and group observations generated by numerous Exadata servers.

You can set the metricStreamTags attribute to a valid JSON string containing tag and value pairs as follows: 

metricStreamTags='{"tag1":"value1"[,"tag2":"value2"]...}'

For example:

CellCLI> ALTER CELL metricStreamTags='{"application":"personnel","department":"HR"}'
7.7.1.2.4.9 Miscellaneous Attributes

Note:

For any attributes not listed here or previously, see DESCRIBE CELL for a description of the attribute.

dbPerfDataSuppress

Use the dbPerfDataSuppress attribute to hide performance output information for specific databases. Specify the databases to mask as a comma-delimited list of names. The performance information for the specified databases is still collected, but is only visible when queried from that database. If you query V$CELL_DB from a different database, then the performance information for the hidden databases appears in the category of OTHER.

diagPackEmailAttach

Use the diagPackEmailAttach attribute to turn on and off adding the diagnostic pack attachment to emails, for example: 

alter cell diagPackEmailAttach=FALSE

See CREATE DIAGPACK for information about diagnostic packs.

diagPackUploadEnabled

Use the diagPackUploadEnabled attribute to enable or disable automatically uploading diagnostic data to a service request using Oracle ASR.

Example 7-30 Enabling/Disabling Auto Diagpack Upload

You can enable or disable this feature by setting the diagPackUploadEnabled attribute on the cell object.

Set the attribute to false to disable this feature, true to enable it. The default is true. 

CellCLI> ALTER CELL diagPackUploadEnabled=FALSE

enableSmartStorage

The enableSmartStorage attribute can be set to TRUE to enable the use of Oracle Exadata System Software capabilities such as Smart Scan and Storage Index on Exadata Extended (XT) Storage Server after you have procured the necessary software licenses.

httpsAccess

Starting with Oracle Exadata System Software release 19.1.0, the httpsAccess attribute can be used to specify a list of IP addresses or IP subnet masks that control who can access the RESTful service via HTTPs. The value you specify for httpsAccess overwrites any previous value. You can use the following values for httpsAccess:

  • ALL — to allow access to all hosts (Default)
  • NONE — to disable the HTTPs port completely
  • IP1, IP2,..., IPn — to only allow access to hosts with IP addresses IP1, IP2,..., IPn where IPn is a valid IP address in IPv4, IPv4 subnet, IPv6 or IPv4-embedded IPv6 format. You can specify a maximum of 512 IP addresses for the access control list.

Additionally, instead of a single IP address, you can use the / character to specify a range of IP addresses using a subnet mask. For example the range '192.168.10.0/24' corresponds to hosts having IP addresses from 192.168.10.1 to 192.168.10.255. If you specify an IP address range, you need to enclose the IP address string in quotes.

Example 7-31 Restricting HTTPS Access to the Exadata RESTful Service

This example shows how to configure an access control list for HTTPs access to the Exadata RESTful service. The following command allows HTTPs port access to hosts having IP addresses in the range from 192.168.10.1 to 192.168.10.255.

CellCLI> ALTER CELL httpsAccess="192.168.10.0/24"

interconnectN

The ALTER CELL interconnectN="" command removes the RDMA Network Fabric configuration information for the cell for the specified interface (N).

If the IP address to an RDMA Network Fabric interface is changed, then the command service openibd restart must be run as the root user before the service network restart command.

After changing an IP address, you must restart all services using the ALTER CELL RESTART SERVICES ALL command.

Example 7-32 Setting RDMA Network Fabric Interconnections

This example shows how to set the RDMA Network Fabric interconnections.

For systems that use InfiniBand Network Fabric, use a command such as the following: 

CellCLI> ALTER CELL interconnect1='ib0', interconnect2='ib1'

For systems that use RoCE Network Fabric, use a command such as the following: 

CellCLI> ALTER CELL interconnect1='re0', interconnect2='re1'

After making the updates, restart all services in the storage server:

CellCLI> ALTER CELL RESTART SERVICES ALL

iotimeoutthreshold

Use the iotimeoutthreshold attribute to change the timeout threshold. If cell I/O takes longer than the defined threshold, then the I/O is canceled, and Oracle ASM redirects the I/O to another mirror copy of the data. Any I/Os issued to the last valid mirror copy of the data are not canceled, even if the timeout threshold is exceeded.

The default value for iotimeoutthreshold is 1000s. The command takes a value, such as 5, and a unit. The valid unit is s, for seconds.

Caution:

Setting the timeout threshold too low can negatively impact system performance. Oracle recommends reviewing the Automatic Workload Repository (AWR) reports of peak I/O loads, and setting the threshold value to a value higher than the peak I/O latency with sufficient safety margin.

Example 7-33 Setting the iotimeoutthreshold Value

This example demonstrates how to set the iotimeoutthreshold to 5 seconds. 

CellCLI> ALTER CELL iotimeoutthreshold = '5s'

To reset the iotimeoutthreshold to the default value, use the following command: 

CellCLI> ALTER CELL iotimeoutthreshold = ""

name

The name attribute contains the host name of the storage server, for example, dm01celladm01.

Example 7-34 Altering Cell Name

This example shows the ALTER command with the CELL object. 

CellCLI> ALTER CELL name=cell02

traceLevel

The level for which trace messages are written. The default is FINE. The value can be:

  • A valid Java logging level

    • SEVERE
    • WARNING
    • INFO
    • CONFIG
    • FINE
    • FINER
    • FINEST

  • A valid Oracle Diagnostic Logging (ODL) logging level

    • INCIDENT_ERROR:1
    • ERROR:1
    • WARNING:1
    • NOTIFICATION:1
    • NOTIFICATION:16
    • TRACE:1
    • TRACE:16
    • TRACE:32

To reset this attribute to its default value, use a value of "".

Examples

Example 7-35 Setting the traceLevel Value to its Default Value

This example shows how to set the traceLevel value to its default value. 

CellCLI> ALTER CELL traceLevel=""
7.7.1.3 ALTER CELLDISK

Purpose

The ALTER CELLDISK command changes the attributes of all cell disks or the specified cell disks.

Syntax

ALTER CELLDISK { ALL [FLASHDISK | HARDDISK | PMEM] | cdisk_name [, cdisk_name]... }
   {{FLUSH [NOWAIT] | CANCEL FLUSH} | 
   { attribute_name = attribute_value 
        [, attribute_name = attribute_value]...
   }

Usage Notes

The attributes that can be changed with the ALTER command are shown as modifiable in Example 7-98.

  • The FLASHDISK option limits the ALTER CELLDISK command to cell disks that are flash disks.

  • The HARDDISK option limits the ALTER CELLDISK command to cell disks that are hard disks.

  • The PMEM option limits the ALTER CELLDISK command to all cell disks of type PMEM.

  • The FLUSH option synchronizes dirty data associated with the specified cell disks. Dirty data is updated data in an Exadata cache (flash cache, PMEM cache, or XRMEM cache) that has not been synchronized with the underlying grid disk. Synchronization of dirty data can be a lengthy process, depending on the number of bytes to be synchronized. Use the following command to check the progress: 

    CellCLI> LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror

  • The ALTER CELLDISK ... FLUSH command must be run before exporting a cell disk to ensure that the dirty data is flushed to the grid disks on the specified cell disk.

  • The FLUSH option stops new data from being cached on the flash cache until CELLSRV restarts, or the flush operation is canceled.

  • The CANCEL FLUSH option terminates an earlier flush operation, and reinstates caching.

  • When the ALTER CELLDISK ... FLUSH command is run for a flash-based cell disk, it synchronizes dirty data from the flash cache located on the specified FDOM to cached grid disks on the specified cell disk. When the command is run for a hard disk-based cell disk, it synchronizes dirty data from the flash cache located on all FDOMs to the grid disks located on the specified cell disk.

Example 7-36 Altering Cell Disk Attributes

This example shows how to change cell disk attributes.

CellCLI> ALTER CELLDISK cdiska name = CD_01_cell01, -
               comment = 'cdiska is now CD_01_cell01'

CellCLI> ALTER CELLDISK ALL -
               comment = 'This cell disk is on cell cell01'

CellCLI> ALTER CELLDISK ALL HARDDISK FLUSH NOWAIT

CellCLI> ALTER CELLDISK c9datafile1 CANCEL FLUSH
7.7.1.4 ALTER FLASHCACHE

Purpose

The ALTER FLASHCACHE command stops new data from being cached on the flash cache and then flushes data not synchronized with the grid disks (dirty data) from flash cache to the specified disks.

Syntax

ALTER FLASHCACHE { ALL [size=fc_size] | CELLDISK="cdisk1 [,cdisk2] ..." [, size=fc_size] [FORCE] }
      { FLUSH [NOWAIT] | CANCEL FLUSH }

Usage Notes

Note:

The FLUSH option stops new data from being cached on the flash cache until CELLSRV restarts, or the flush operation is canceled with the ALTER FLASHCACHE CANCEL FLUSH command.

  • The ALL option affects all available flash cell disks.

  • The CELLDISK option allows specific cell disks to be flushed.

  • The FORCE option allows you to forcefully change the set of cell disks used by the flash cache.

  • If specified, the size attribute re-sizes the flash cache. The value is validated.

    If a valid size is specified in conjunction with the ALL option, then the flash cache is dropped and re-created on all of the cell disks using the specified size.

    If a valid size is specified in conjunction with the CELLDISK option, then the flash cache is dropped and re-created on the specified cell disks using the specified size.

  • The FLUSH option synchronizes dirty data from the flash cache to the grid disks. Dirty data is data that has not been synchronized with the grid disk. Synchronization of dirty data can be a lengthy process, depending on the number of bytes to be synchronized. Use the following command to check the progress: 

    LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror

  • The ALTER FLASHCACHE CELLDISK= ... FLUSH command does not flush the dirty data when the data cannot be read from the flash cache or written to disk. To flush the dirty data from the flash disk to grid disks use the ALTER GRIDDISK ... FLUSH command.

  • The ALTER FLASHCACHE ... FLUSH command stops new data from being written to the flash cache and then synchronizes all data in the flash cache with the hard disks. As a result, all data is removed from the flash cache. When the flash cache is re-enabled, the flash cache activity metrics are reset.

  • The CANCEL FLUSH option terminates an earlier flush operation, and reinstates flash caching.

  • The NOWAIT option allows the ALTER command to complete while the flush operation is in progress.

  • By default, 5 percent of space on Extreme Flash storage servers is used for write-back flash cache.

Example 7-37 Flushing Dirty Blocks from Flash Cell Disks

This example shows how to flush dirty blocks from all flash cell disks.

CellCLI> ALTER FLASHCACHE ALL FLUSH
Flash cache on FD_00_scac01cel07 successfully altered
Flash cache on FD_01_scac01cel07 successfully altered
Flash cache on FD_02_scac01cel07 successfully altered
...
Flash cache on FD_14_scac01cel07 successfully altered
Flash cache on FD_15_scac01cel07 successfully altered

Parent topic: ALTER

7.7.1.5 ALTER GRIDDISK

Purpose

The ALTER GRIDDISK command changes the attributes of all grid disks or specified grid disks.

Caution:

Before changing the name of a grid disk that belongs to an Oracle ASM disk group, ensure that the Oracle ASM disk group is offline.

Syntax

ALTER GRIDDISK { ALL [ FLASHDISK | HARDDISK ] | gdisk_name1 [,gdisk_name2] ... }
      { attribute_filters { ACTIVE | INACTIVE | { FLUSH [NOWAIT] | CANCEL FLUSH } } |
          attribute_name = attribute_value [, attribute_name = attribute_value] ...
              [ attribute_filters ] [NOWAIT] }

Command Options

  • The FLASHDISK option limits the ALTER GRIDDISK command to grid disks that are flash disks.

  • The HARDDISK option limits the ALTER GRIDDISK command to grid disks that are hard disks.

  • The ACTIVE option notifies CELLSRV to accept I/O as normal for the specified grid disks. The grid disks are visible to the database clients.

  • The INACTIVE option makes the grid disks visible to the cell administrator, but not visible to the database clients. CELLSRV treats the grid disks as if they were offline. This mode allows management operations on the grid disks. You can do upgrading and testing on the grid disks before making the grid disks visible to database users. This functionality is similar to starting up a database in RESTRICTED mode.

    Note:

    When a grid disk that is currently in use by a database client is made INACTIVE, Oracle ASM takes the corresponding Oracle ASM disk offline when I/Os to the disk fail. To make the disk usable again, make the grid disk ACTIVE in the cell, and then bring the corresponding Oracle ASM disk back online in Oracle ASM.

  • The FLUSH option synchronizes dirty data from the flash cache to the grid disks. Dirty data is data that has not been synchronized with the grid disk.

    Synchronization of dirty data can be a lengthy process, depending on the number of bytes to be synchronized. Use the following command to check the progress: 

    LIST GRIDDISK ATTRIBUTES name, flushstatus

  • The CANCEL FLUSH option terminates an earlier flush operation.

  • The NOWAIT option allows the ALTER command to complete while a resize or flush operation continues, for example:

  • Starting with Oracle Exadata System Software release 20.1.0, the ALTER GRIDDISK command accepts a WHERE clause, which allows for a specific subset of grid disks to be altered. For example, if you have two sets of grid disks, one for DATA and the other for RECO, you can use the WHERE clause to resize the grid disks from one disk group only, for example: 

    ALTER GRIDDISK size=5T WHERE name like 'RECO.*'

    You can use the WHERE clause with either a list of grid disks or with the ALL {FLASHDISK|HARDDISK} option. If you use the WHERE clause and do not specify either a list of grid disks or the ALL {FLASHDISK|HARDDISK} option, then the WHERE clause acts against all disks. Some examples of this syntax are: 

    ALTER GRIDDISK WHERE name like 'DATA.*' INACTIVE

ALTER GRIDDISK ALL FLASHDISK FLUSH NOWAIT

Usage Notes

The attributes that can be changed with the ALTER GRIDDISK command are shown as modifiable in Example 7-104.

  • The length of a grid disk name is limited to 30 characters.

  • The FLUSH option stops new data from being cached on the specified grid disks until CELLSRV restarts, or the flush operation is canceled.

  • The FLUSH option is valid for write back disks, not write through disks.

  • The size attribute can be specified to expand or reduce space allocated to a grid disk. The corresponding Oracle ASM disk must be resized separately.

    The size attribute is specified as a number in bytes, unless the suffix M (megabytes) or G (gigabytes) is included with the number value. Grid disk space is allocated in 16 MB units, referred to as allocation units. The actual size allocated is the size of the largest multiple of allocation units less than or equal to the specified size. The minimum value is 16 MB. Values less than 16 MB are rounded up to 16 MB.

  • A grid disk should not be renamed when the grid disk is being accessed. If you try to rename a grid disk when it is being accessed, then the operation fails. You can make the grid disk inactive or dismount the Oracle ASM disk group to stop access to the grid disk before renaming it.

  • When an interleaved grid disk is resized, the contents of the grid disk are moved to achieve the interleaved space allocation across the cell disk. The resizing operation can take a few minutes. You can choose to have the data movement proceed as a background process by using the NOWAIT option. Use the LIST GRIDDISK command to check the status.

    Note:

    Interleaved grid disks are deprecated in Oracle Exadata System Software release 19.1.0.

  • The cachingPolicy attribute specifies the flash caching policy for the grid disk.

    Flash cache is effectively disabled for database files located in a disk group composed of grid disks having cachingPolicy set to none. You may choose this because:

    • You want specific database files persisted directly to disk instead of utilizing write-back flash cache. This is particularly useful in situations where the durability of disk storage outweighs the performance of flash storage.

    • You want to dedicate flash cache resources to objects in other database files.

    Use the following commands to set the cachingPolicy attribute to none: 

    ALTER GRIDDISK grid_disk_name CACHINGPOLICY="none"
ALTER GRIDDISK grid_disk_name FLUSH
-- Wait for the FLUSH to complete.
ALTER GRIDDISK grid_disk_name CANCEL FLUSH

    To re-enable caching on the grid disk:

    ALTER GRIDDISK grid_disk_name CACHINGPOLICY="default"

    By default, OEDA configures the RECO disk group grid disks with cachingPolicy set to none. Consequently, flash cache is not used for any database files placed in RECO.

Example 7-38 Altering Grid Disk Attributes

This example shows the ALTER command with the GRIDDISK object. 

CellCLI> ALTER GRIDDISK data1_CD_01_cell01, data2_CD_01_cell01
         comment = "This grid disk is on cell01"

CellCLI> ALTER GRIDDISK ALL INACTIVE
7.7.1.6 ALTER IBPORT

Purpose

The ALTER IBPORT command performs an action on all InfiniBand Network Fabric ports, or specified InfiniBand Network Fabric ports.

Note:

This command does not apply to Oracle Exadata X8M systems.

Syntax

ALTER IBPORT {ALL | ibport_name [, ibport_name] ...} RESET COUNTERS

Usage Notes

The RESET COUNTERS option resets all counters on the InfiniBand Network Fabric port.

Example 7-39 Altering IBPORT Attributes

This example shows the ALTER command with the IBPORT object. 

CellCLI> ALTER IBPORT ALL RESET COUNTERS

         InfiniBand Port HCA-1:1 successfully altered.
         InfiniBand Port HCA-1:2 successfully altered.
 
CellCLI> ALTER IBPORT "HCA-1:1" RESET COUNTERS

         InfiniBand Port HCA-1:1 successfully altered.

Parent topic: ALTER

7.7.1.7 ALTER IORMPLAN

Purpose

The ALTER IORMPLAN command updates the IORM plan for the cell.

The ALTER IORMPLAN command clauses control the IORM objective and specify directives that control access to I/O resources.

Syntax

ALTER IORMPLAN [ objective = iorm_objective ]
      [ catplan = { ( directive [, directive] ... ) | "" } ]
      [ dbplan = { ( directive [, directive] ... ) | "" } ]
      [ clusterplan = { ( directive [, directive] ... ) | ""  } ]

Parameters

  • objective: Specifies the optimization mode for IORM. The valid objective values are:

    • auto - Use this setting for IORM to determine the best mode based on active workloads and resource plans. IORM continuously and dynamically determines the optimization objective, based on the observed workloads and enabled resource plans. This is the recommended value for most use cases, and starting with Oracle Exadata System Software release 21.2.0, this is the default setting.
    • high_throughput - Use this setting to optimize critical DSS workloads that require high throughput. This setting improves throughput at the cost of I/O latency.
    • low_latency - Use this setting to optimize critical OLTP workloads that require extremely good disk latency. This setting provides the lowest possible latency at the cost of throughput by limiting disk utilization.
    • balanced - Use this setting for a mixture of critical OLTP and DSS workloads. This setting balances low disk latency and high throughput. This setting limits disk utilization of large I/Os to a lesser extent than low_latency to achieve a balance between latency and throughput.
    • basic: Use this setting to limit the maximum small I/O latency and otherwise disable I/O prioritization. This is the default setting in Oracle Exadata System Software release 20.1.0 and earlier.

  • catplan: Specifies the category plan, allowing you to allocate resources primarily by the category of the work being done. If no catplan directives are set, then every category has an equal share of the resources by default.

    Note:

    Starting with Oracle Exadata System Software release 21.2.0, the category plan is deprecated and a warning message is issued when a category plan is set.

  • dbplan: Specifies the interdatabase plan, allowing you to manage resource allocations among databases. If no dbplan directives are set, then every database has an equal share of the resources by default.

  • clusterplan: Specifies the cluster plan, allowing you to manage resource allocations among Oracle Grid Infrastructure clusters. If no clusterplan directives are set, then every cluster has an equal share of the resources by default.

    Note:

    The cluster plan is first introduced in Oracle Exadata System Software release 21.2.0.

Usage Notes

  • To fully enable any user-defined IORM plans (catplan, dbplan, or clusterplan), the IORM objective must be set to a value other than basic.

  • The cluster plan (clusterplan) uses ASM-scoped security for cluster identification. The value of the name attribute must match the asm field in the cellkey.ora file, which is part of the ASM-scoped security definition for the cluster. If ASM-scoped security is not configured, then all databases in the cluster are associated with the DEFAULT cluster.

  • Different user-defined IORM plans inter-operate as follows:

    • The catplan and dbplan can be used in combination only if the dbplan does not contain any directives having type=profile.

      In this case, directives from both plans are applied to determine the share of resources.

    • The catplan and clusterplan cannot be used in combination.

      You cannot set clusterplan directives when catplan directives exist. Likewise, you cannot set catplan directives when clusterplan directives exist.

    • The clusterplan and dbplan can be used in combination only if the dbplan does not contain any allocation or level directives.

      In this case, directives from both plans are applied to determine the share of resources.

  • To remove the current directives and reset a catPlan, dbPlan, or clusterplan parameter, set the parameter to an empty string by using a pair of single or double quotation marks. The quotation marks must match. For example, "" is correct, but "' is incorrect.

  • Because of the command length and complexity, consider running ALTER IORMPLAN commands by using scripts.

Example 7-40 Setting the IORMPLAN Objective

This example shows the ALTER IORMPLAN command being used to set the IORM optimization mode. 

CellCLI> ALTER IORMPLAN objective=low_latency
CellCLI> ALTER IORMPLAN objective=auto

Example 7-41 Resetting IORMPLAN Plans

This example shows how to reset the IORMPLAN dbplan and catplan. The first command resets the dbplan and catplan using one command. The other commands reset the dbplan and catplan individually. 

CellCLI> ALTER IORMPLAN dbplan="", catplan=""
CellCLI> ALTER IORMPLAN dbplan=""
CellCLI> ALTER IORMPLAN catplan=""
7.7.1.7.1 Directives for a Category Plan

The directives for a category plan (catplan) use the following syntax: 

( name=category_name , level=number, allocation=number )

Usage Notes

  • The name attribute must be the first attribute listed in each directive. Otherwise, the order of attributes is not important.
  • The category plan can have a maximum of 32 directives.
  • You cannot have multiple directives with the same category name.

See the following topics for details about the attributes (name, level, and allocation) that are defined in each catplan directive.

Parent topic: ALTER IORMPLAN

7.7.1.7.2 Directives for a Database Plan

The directives for a database plan (dbplan) use the following syntax: 

( name={ db_name | profile_name }
  [, { share=number | level=number, allocation=number }]
  [, limit=number]
  [, flashcache={on|off}]
  [, xrmemcache={on|off}]
  [, pmemcache={on|off}]
  [, flashlog={on|off}]
  [, xrmemlog={on|off}]
  [, pmemlog={on|off}]
  [, flashcachelimit=number]
  [, flashcachemin=number]
  [, flashcachesize=number]
  [, xrmemcachelimit=number]
  [, xrmemcachemin=number]
  [, xrmemcachesize=number]
  [, pmemcachelimit=number]
  [, pmemcachemin=number]
  [, pmemcachesize=number]
  [, asmcluster=asm_cluster_name]
  [, type={database|profile}]
  [, role={primary|standby}] )

Usage Notes

  • The name attribute must be the first attribute listed in each directive. Otherwise, the order of attributes is not important.
  • The database plan cannot contain a mixture of resource allocation directives, with some using the share attribute and others using the level and allocation attributes. The resource allocation directives must all use the share attribute, or they must all use the level and allocation attributes.
  • If you use the share attribute to allocate I/O resources, then the database plan can have a maximum of 1024 directives. If you use the level and allocation attributes to allocate I/O resources, then the database plan can have a maximum of 32 directives.
  • Only one active directive is allowed for each database name and each profile name.

See the following topics for details about the attributes that can be defined in each dbplan directive.

Parent topic: ALTER IORMPLAN

7.7.1.7.3 Directives for a Cluster Plan

The directives for a cluster plan (clusterplan) use the following syntax: 

( name=cluster_name [, share=number] [, limit=number] )

Usage Notes

  • The name attribute must be the first attribute listed in each directive. Otherwise, the order of attributes is not important.
  • The cluster plan can have a maximum of 1024 directives.
  • You cannot have multiple directives with the same cluster name.

See the following topics for details about the attributes that can be defined in each clusterplan directive.

Parent topic: ALTER IORMPLAN

7.7.1.7.4 name Attribute

Purpose

The name attribute identifies the entity that is the subject of the directive.

Syntax

ALTER IORMPLAN 
   catplan = (( name=category_name, ... ) ... )
ALTER IORMPLAN 
   dbplan = (( name={ db_name | profile_name }, ... ) ... )
ALTER IORMPLAN 
   clusterplan = (( name=cluster_name, ... ) ... )

Usage Notes

  • For directives in a category plan (catplan), the name attribute specifies the category name. Oracle Database manages intra-database resources using Database Resource Manager (DBRM). DBRM manages resources across consumer groups, and each consumer group is associated with a category. The catplan category name is associated with any DBRM category having the same name.

  • For directives in a database plan (dbplan), the name attribute usually identifies the database that is associated with the directive. However, when the directive includes type=profile, the name attribute specifies the profile name.

    In directives that identify a database, the name value usually matches with the value of the DB_UNIQUE_NAME database parameter. The exception is where the directive uses the role attribute to manage an Oracle Data Guard configuration. For further details, see role Attribute.

  • For directives in a cluster plan (clusterplan), the name attribute identifies the Oracle Grid Infrastructure cluster that is associated with the directive. The cluster plan (clusterplan) uses ASM-scoped security for cluster identification. The value of the name attribute must match the asm field in the cellkey.ora file, which is part of the ASM-scoped security definition for the cluster.

  • The name attribute must be the first attribute in a directive.

  • The name attribute value cannot start with an underscore (_).

  • Each name must be followed by at least one other attribute, for example:

    • (name=sales, share=8)
    • (name=oltpdg, limit=80)
    • (name=dwh, flashcachesize=50G)

  • There are two special name values:

    • OTHER: names a special directive that defines the resource allocation for all other entities that are not specified in the plan. All entities that are not explicitly named in the plan share the resources associated with the OTHER directive.

      The OTHER directive is used in database plans and category plans that use allocation-based resource management; that is, resource allocation defined using the level and allocation attributes. Plans with allocation-based directives must also include an OTHER directive.

      In a database plan, the limit attribute can also be defined in the OTHER directive.

    • DEFAULT: names a special directive that defines the resource allocation for each entity that is not specified in the plan. Every entity that is not explicitly named in the plan receives the resources in the DEFAULT directive.

      The DEFAULT directive is available in database plans and cluster plans that use share-based resource allocation; that is, resource allocation defined using the share attribute.

      If ASM-scoped security is not configured, then all databases in the cluster are associated with the DEFAULT cluster.

Example 7-42 Using the name Attribute in a Database Plan

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=db1, limit=50),                         -
                 (name=db2, limit=50),                         -
                 (name=OTHER, level=1, allocation=25))

Example 7-43 Setting a Database Plan with a DEFAULT Directive

This example shows how to use the DEFAULT directive to set the default share allocation for all databases except dev01 and dev02. 

CellCLI> ALTER IORMPLAN                                             -
         dbplan=((name=dev01, share=1, limit=50, flashlog=off),     -
                 (name=dev02, share=1, limit=25, flashcache=off),   -
                 (name=DEFAULT, share=4))

Parent topic: ALTER IORMPLAN

7.7.1.7.5 share Attribute

Purpose

The share attribute controls share-based resource allocation, which specifies the relative priority for a database in a dbplan or a cluster in a clusterplan. A higher share value implies higher priority and more access to the I/O resources.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... share=number ... ) ... )
 ALTER IORMPLAN 
   clusterplan=(( name=cluster_name, ... share=number ... ) ... )

Usage Notes

  • share: Specifies the resource allocation share.

    Valid values are 1 to 32, with 1 being the lowest share, and 32 being the highest share. The share value represents the relative importance of each entity. A higher share value implies higher priority and more access to resources. The sum of all share values in a plan cannot be greater than 32768.

  • For share-based resource allocation, name=DEFAULT is used to define the default share for each entity that is not specified in the IORM plan.

  • Share-based resource allocation is the recommended method for a database plan (dbplan). For a cluster plan (clusterplan), share-based resource allocation is the only option.

Example 7-44 Setting a Database Plan Using the share Attribute

This example shows how to configure dbPlan using the share attribute. 

CellCLI> ALTER IORMPLAN                                                 -
         dbplan=((name=sales01, share=4),                               -
                 (name=sales02, share=4),                               -
                 (name=fin01, share=3),                                 -
                 (name=fin02, share=2),                                 -
                 (name=dev01, share=1, limit=50, flashLog=off),         -
                 (name=dev02, share=1, limit=25, flashCache=off),       -
                 (name=DEFAULT, share=2))

Parent topic: ALTER IORMPLAN

7.7.1.7.6 allocation and level Attributes

Purpose

The level and allocation attributes control allocation-based resource management. You can use allocation-based resource management to control I/O distribution for a database in a dbplan or a workload category in a catplan.

Syntax

 ALTER IORMPLAN 
   catplan=(( name=category_name, level=number, allocation=number ) ... )
 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... level=number, allocation=number ... ) ... )

Usage Notes

  • level: Specifies the allocation level.

    Valid values are from 1 to 8. Resources are allocated to level 1 first, and then remaining resources are allocated to level 2, and so on.

  • allocation: Specifies the resource allocation as a percentage (0-100) within the level.

    For each level, the sum of allocation values cannot exceed 100.

  • For allocation-based resource management, name=OTHER is used to define the resource allocation to share across all entities that are not specified in the IORM plan. Plans (dbplan or catplan) with allocation-based directives must also include a directive with name=OTHER.

Example 7-45 Using the level and allocation Attributes

These examples show the ALTER command with the level and allocation attributes. 

CellCLI> ALTER IORMPLAN                                          -
        catplan=((name=administrative, level=1, allocation=80),  -
                 (name=interactive, level=2, allocation=90),     -
                 (name=batch, level=3, allocation=80),           -
                 (name=maintenance, level=4, allocation=50),     -
                 (name=other, level=4, allocation=50)),          -
        dbplan=((name=sales_prod, level=1, allocation=80),       -
                (name=finance_prod, level=1, allocation=20),     -
                (name=sales_dev, level=2, allocation=100),       -
                (name=sales_test, level=3, allocation=50),       -
                (name=other, level=3, allocation=50))
CellCLI> ALTER IORMPLAN                                         -
         catplan=((name=interactive, level=1, allocation=90),   -
                  (name=batch, level=2, allocation=80),         -
                  (name=maintenance, level=3, allocation=50),   -
                  (name=other, level=3, allocation=50))

Parent topic: ALTER IORMPLAN

7.7.1.7.7 limit Attribute

Purpose

The limit attribute specifies the maximum flash I/O utilization limit.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... limit=number ... ) ... )
 ALTER IORMPLAN 
   clusterplan=(( name=cluster_name, ... limit=number ... ) ... )

Usage Notes

  • limit: Specifies the maximum flash I/O utilization limit as a percentage of the available resources. The attribute applies only to I/O on flash devices, which includes flash-based grid disks and Exadata Smart Flash Cache.

    Valid values are 1 to 100. If a limit is specified, then excess capacity is never used by the associated database or cluster. Consequently, it is possible for flash devices to run below full capacity when limits are specified.

    Note:

    Specifying low limit values can have a significant performance impact and is generally not advisable.

  • Resource management using limits is ideal for pay-for-performance use cases but should not be used to implement fairness. Instead, use the share attribute to ensure equitable distribution of I/O resources.

Example 7-46 Using the limit Attribute with a Database Plan

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=db1, limit=40),                         -
                 (name=db2, limit=40),                         -
                 (name=DEFAULT, limit=20))

Parent topic: ALTER IORMPLAN

7.7.1.7.8 flashcache Attribute

Purpose

The flashcache attribute controls use of Exadata Smart Flash Cache by a database. This ensures that cache space is reserved for mission-critical databases.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashcache={on|off}  ... ) ... )

Usage Notes

  • By default, any database can use Exadata Smart Flash Cache unless it is affected by a directive that specifies flashcache=off.

  • flashcache=off is invalid in a directive that contains the flashcachemin, flashcachelimit, or flashcachesize attributes.

Example 7-47 Setting Flash Cache Use in a Database Plan

This example shows how to enable Flash Cache use in a database plan.

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=sales_prod, flashcache=on),             -
                 (name=sales_dev, flashcache=on),              -
                 (name=sales_test, flashcache=off),            -
                 (name=DEFAULT, flashcache=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.9 xrmemcache Attribute

Purpose

The xrmemcache attribute controls use of the Exadata RDMA Memory Cache (XRMEM cache) by a database. This ensures that cache space is reserved for mission-critical databases.

Syntax

ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemcache={on|off}  ... ) ... )

Usage Notes

  • By default, any database can use the XRMEM cache unless it is affected by a directive that specifies xrmemcache=off.

  • xrmemcache=off is invalid in a directive that contains the xrmemcachemin, xrmemcachelimit, or xrmemcachesize attributes.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

    For backward compatibility, on Exadata X8M and X9M systems, you can use pmemcache instead of xrmemcache in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemcache.

Example 7-48 Setting XRMEM Cache Use in a Database Plan

This example shows how to enable XRMEM cache use in a database plan. 

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=sales_prod, xrmemcache=on),             -
                 (name=sales_dev, xrmemcache=off),             -
                 (name=sales_test, xrmemcache=off),            -
                 (name=DEFAULT, xrmemcache=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.10 pmemcache Attribute

Purpose

The pmemcache attribute controls use of the persistent memory (PMEM) cache by a database. This ensures that cache space is reserved for mission-critical databases.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemcache Attribute.

Syntax

ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemcache={on|off}  ... ) ... )

Usage Notes

  • By default, any database can use the PMEM cache unless it is affected by a directive that specifies pmemcache=off.

  • pmemcache=off is invalid in a directive that contains the pmemcachemin, pmemcachelimit, or pmemcachesize attributes.

Example 7-49 Setting PMEM Cache Use in a Database Plan

This example shows how to enable PMEM cache use in a database plan.

CellCLI> ALTER IORMPLAN                                        -
         dbplan=((name=sales_prod, pmemcache=on),             -
                 (name=sales_dev, pmemcache=off),             -
                 (name=sales_test, pmemcache=off),            -
                 (name=DEFAULT, pmemcache=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.11 flashlog Attribute

Purpose

The flashlog attribute controls use of Exadata Smart Flash Log by a database. This ensures that Exadata Smart Flash Log is reserved for mission-critical databases.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashlog={on|off}  ... ) ... )

Usage Notes

  • By default, any database can use Exadata Smart Flash Log unless it is affected by a directive that specifies flashlog=off.

Example 7-50 Setting Flash Log Use in a Database Plan

This example shows how to control Flash Log use in a database plan.

CellCLI> ALTER IORMPLAN                                                                       -
         dbplan=((name=oltp, level=1, allocation=80, flashcache=on, flashlog=on),             -
                 (name=dss, level=1, allocation=20, limit=50, flashcache=off, flashlog=off),  -
                 (name=OTHER, level=2, allocation=100),                                       -
                 (name=DEFAULT, flashcache=off, flashlog=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.12 xrmemlog Attribute

Purpose

The xrmemlog attribute controls use of the XRMEM log by a database. This ensures that commit acceleration is reserved for mission-critical databases.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemlog={on|off}  ... ) ... )

Usage Notes

  • By default, any database can use XRMEM log unless it is affected by a directive that specifies xrmemlog=off.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory commit accelerator, previously known as PMEM log, is now called XRMEM log.

    For backward compatibility, on Exadata X8M and X9M systems, you can use pmemlog instead of xrmemlog in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemlog.

Example 7-51 Setting XRMEM Log Use in a Database Plan

This example shows how to control XRMEM Log use in a database plan.

CellCLI> ALTER IORMPLAN                                                                      -
         dbplan=((name=oltp, level=1, allocation=80, xrmemcache=on, xrmemlog=on),              -
                 (name=dss, level=1, allocation=20, limit=50, xrmemcache=off, xrmemlog=off),   -
                 (name=OTHER, level=2, allocation=100),                                      -
                 (name=DEFAULT, xrmemcache=off, xrmemlog=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.13 pmemlog Attribute

Purpose

The pmemlog attribute controls use of the persistent memory commit accelerator (PMEM log) by a database. This ensures that commit acceleration is reserved for mission-critical databases.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemlog Attribute.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemlog={on|off}  ... ) ... )

Usage Notes

  • By default, any database can use PMEM log unless it is affected by a directive that specifies pmemlog=off.

Example 7-52 Setting PMEM Log Use in a Database Plan

This example shows how to control PMEM Log use in a database plan.

CellCLI> ALTER IORMPLAN                                                                      -
         dbplan=((name=oltp, level=1, allocation=80, pmemcache=on, pmemlog=on),              -
                 (name=dss, level=1, allocation=20, limit=50, pmemcache=off, pmemlog=off),   -
                 (name=OTHER, level=2, allocation=100),                                      -
                 (name=DEFAULT, pmemcache=off, pmemlog=off))

Parent topic: ALTER IORMPLAN

7.7.1.7.14 flashcachelimit Attribute

Purpose

The flashcachelimit attribute defines a soft limit for space usage in Exadata Smart Flash Cache. If the cache is not full, the limit can be exceeded.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashcachelimit=number ... ) ... )

Usage Notes

  • You specify the value for flashcachelimit in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for flashcachelimit must be at least 4 MB.

  • The flashcachelimit and flashcachesize attributes cannot be specified in the same directive.

  • The value for flashcachelimit cannot be smaller than flashcachemin, if it is specified.

Example 7-53 Specifying Flash Cache Quotas in a Database Plan

This example shows how to configure flash cache quotas in a database plan.

CellCLI> ALTER IORMPLAN                                                          -
         dbplan=((name=prod, share=8, flashCacheMin=400M),                       -
                 (name=dev,  share=2, flashCacheMin=100M, flashCacheLimit=200M), -
                 (name=test, share=1, limit=40, flashCacheLimit=20M))

Parent topic: ALTER IORMPLAN

7.7.1.7.15 flashcachemin Attribute

Purpose

The flashcachemin attribute specifies a minimum guaranteed space allocation in Exadata Smart Flash Cache.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashcachemin=number ... ) ... )

Usage Notes

  • You specify the value for flashcachemin in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for flashcachemin must be at least 4 MB.

  • In any plan, the sum of all flashcachemin values cannot exceed the size of Exadata Smart Flash Cache.

  • If flashcachelimit is specified, then the value for flashcachemin cannot exceed flashcachelimit.

  • If flashcachesize is specified, then the value for flashcachemin cannot exceed flashcachesize.

Parent topic: ALTER IORMPLAN

7.7.1.7.16 flashcachesize Attribute

Purpose

The flashcachesize attribute defines a hard limit for space usage in Exadata Smart Flash Cache. The limit cannot be exceeded, even if the cache is not full.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... flashcachesize=number ... ) ... )

Usage Notes

  • You specify the value for flashcachesize in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for flashcachesize must be at least 4 MB.

  • The flashcachelimit and flashcachesize attributes cannot be specified in the same directive.

  • The value for flashcachesize cannot be smaller than flashcachemin, if it is specified.

  • In an IORM plan, if the size of Exadata Smart Flash Cache can accommodate all of the flashcachemin and flashcachesize allocations, then each flashcachesize definition represents a guaranteed space allocation.

    However, starting with Oracle Exadata System Software release 19.2.0 you can use the flashcachesize attribute to over-provision space in Exadata Smart Flash Cache. Consequently, if the size of Exadata Smart Flash Cache cannot accommodate all of the flashcachemin and flashcachesize allocations, then only flashcachemin is guaranteed.

Parent topic: ALTER IORMPLAN

7.7.1.7.17 xrmemcachelimit Attribute

Purpose

The xrmemcachelimit attribute defines a soft limit for space usage in the Exadata RDMA Memory Cache (XRMEM cache). If the cache is not full, the limit can be exceeded.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemcachelimit=number ... ) ... )

Usage Notes

  • You specify the value for xrmemcachelimit in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for xrmemcachelimit must be at least 4 MB.

  • The xrmemcachelimit and xrmemcachesize attributes cannot be specified in the same directive.

  • The value for xrmemcachelimit cannot be smaller than xrmemcachemin, if it is specified.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

    For backward compatibility, on Exadata X8M and X9M systems, you can use pmemcachelimit instead of xrmemcachelimit in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemcachelimit.

Parent topic: ALTER IORMPLAN

7.7.1.7.18 xrmemcachemin Attribute

Purpose

The xrmemcachemin attribute specifies a minimum guaranteed space allocation in the Exadata RDMA Memory Cache (XRMEM cache).

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemcachemin=number ... ) ... )

Usage Notes

  • You specify the value for xrmemcachemin in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for xrmemcachemin must be at least 4 MB.

  • In any plan, the sum of all xrmemcachemin values cannot exceed the size of the XRMEM cache.

  • If xrmemcachelimit is specified, then the value for xrmemcachemin cannot exceed xrmemcachelimit.

  • If xrmemcachesize is specified, then the value for xrmemcachemin cannot exceed xrmemcachesize.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

    For backward compatibility, on Exadata X8M and X9M systems, you can use pmemcachemin instead of xrmemcachemin in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemcachemin.

Parent topic: ALTER IORMPLAN

7.7.1.7.19 xrmemcachesize Attribute

Purpose

The xrmemcachesize attribute defines a hard limit for space usage in the Exadata RDMA Memory Cache (XRMEM cache). The limit cannot be exceeded, even if the cache is not full.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... xrmemcachesize=number ... ) ... )

Usage Notes

  • You specify the value for xrmemcachesize in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for xrmemcachesize must be at least 4 MB.

  • The xrmemcachelimit and xrmemcachesize attributes cannot be specified in the same directive.

  • The value for xrmemcachesize cannot be smaller than xrmemcachemin, if it is specified.

  • In an IORM plan, if the size of the XRMEM cache can accommodate all of the xrmemcachemin and xrmemcachesize allocations, then each xrmemcachesize definition represents a guaranteed space allocation.

    However, you can use the xrmemcachesize attribute to over-provision space in the XRMEM cache. Consequently, if the XRMEM cache size cannot accommodate all of the xrmemcachemin and xrmemcachesize allocations, then only xrmemcachemin is guaranteed.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache.

    For backward compatibility, on Exadata X8M and X9M systems, you can use pmemcachesize instead of xrmemcachesize in the ALTER IORMPLAN command. However, starting with Oracle Exadata System Software release 23.1.0, output from the LIST IORMPLAN command only displays xrmemcachesize.

Parent topic: ALTER IORMPLAN

7.7.1.7.20 pmemcachelimit Attribute

Purpose

The pmemcachelimit attribute defines a soft limit for space usage in the persistent memory (PMEM) cache. If the cache is not full, the limit can be exceeded.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemcachelimit Attribute.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemcachelimit=number ... ) ... )

Usage Notes

  • You specify the value for pmemcachelimit in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for pmemcachelimit must be at least 4 MB.

  • The pmemcachelimit and pmemcachesize attributes cannot be specified in the same directive.

  • The value for pmemcachelimit cannot be smaller than pmemcachemin, if it is specified.

Parent topic: ALTER IORMPLAN

7.7.1.7.21 pmemcachemin Attribute

Purpose

The pmemcachemin attribute specifies a minimum guaranteed space allocation in the persistent memory (PMEM) cache.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemcachemin Attribute.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemcachemin=number ... ) ... )

Usage Notes

  • You specify the value for pmemcachemin in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for pmemcachemin must be at least 4 MB.

  • In any plan, the sum of all pmemcachemin values cannot exceed the size of the PMEM cache.

  • If pmemcachelimit is specified, then the value for pmemcachemin cannot exceed pmemcachelimit.

  • If pmemcachesize is specified, then the value for pmemcachemin cannot exceed pmemcachesize.

Parent topic: ALTER IORMPLAN

7.7.1.7.22 pmemcachesize Attribute

Purpose

The pmemcachesize attribute defines a hard limit for space usage in the persistent memory (PMEM) cache. The limit cannot be exceeded, even if the cache is not full.

Note:

This attribute applies to Oracle Exadata System Software releases before 23.1.0. Otherwise, see xrmemcachesize Attribute.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... pmemcachesize=number ... ) ... )

Usage Notes

  • You specify the value for pmemcachesize in bytes. You can also use the suffixes M (megabytes), G (gigabytes), or T (terabytes) to specify larger values. For example, 300M, 150G, or 1T.

  • The value for pmemcachesize must be at least 4 MB.

  • The pmemcachelimit and pmemcachesize attributes cannot be specified in the same directive.

  • The value for pmemcachesize cannot be smaller than pmemcachemin, if it is specified.

  • In an IORM plan, if the size of the PMEM cache can accommodate all of the pmemcachemin and pmemcachesize allocations, then each pmemcachesize definition represents a guaranteed space allocation.

    However, you can use the pmemcachesize attribute to over-provision space in the PMEM cache. Consequently, if the PMEM cache size cannot accommodate all of the pmemcachemin and pmemcachesize allocations, then only pmemcachemin is guaranteed.

Parent topic: ALTER IORMPLAN

7.7.1.7.23 asmcluster Attribute

Purpose

Starting with Oracle Exadata System Software release 19.1.0, you can use the asmcluster attribute to distinguish between databases with the same name running in different Oracle ASM clusters.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... asmcluster=asm_cluster_name ... ) ... )

Usage Notes

  • To use the asmcluster attribute, ASM-scoped security must be configured.

  • The value of the asmcluster attribute must match the asm field in the cellkey.ora file, which is part of the ASM-scoped security definition for the cluster.

  • You cannot use the asmcluster attribute in conjunction with allocation-based resource management (using the level and allocation attributes).

Example 7-54 Using the asmcluster Attribute

This example shows how to use the asmcluster attribute to distinguish between databases with the same name. 

CellCLI> ALTER IORMPLAN                                                           -
         dbPlan=((name=prod1, share=4, flashcachemin=5G, asmcluster=cluster1),    -
                 (name=prod1, share=2, limit=80, asmcluster=cluster2),            -
                 (name=prod2, share=2, flashcachelimit=2G, asmcluster=cluster1),  -
                 (name=DEFAULT, share=1, flashcachelimit=1G))

Parent topic: ALTER IORMPLAN

7.7.1.7.24 role Attribute

Purpose

The role attribute enables you specify different plan directives based on the Oracle Data Guard database role. The directive for a database is applied only when the database is in the specified role. New directives are automatically applied by IORM when a database changes roles because of an Oracle Data Guard switchover or fail-over.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... role={primary|standby} ... ) ... )

Usage Notes

  • Directives using the role attribute must be defined in matched pairs, using the same name value. That is, for each directive that specifies role=primary, you must have a corresponding directive that specifies role=standby. Likewise, each standby directive must have a matching primary directive.

  • You must use the same name value to identify the database in both the primary directive and the standby directive. To achieve this, you can:

    • Set the name attribute to the value of the DB_UNIQUE_NAME parameter in the standby database, and set the DB_NAME parameter in the primary database to the same value. This option allows you to define specific directives to manage multiple standby databases.

    • Set the name attribute to the value of the DB_NAME database parameter, which will be the same in the primary and standby databases. This option is not recommended for cases supporting multiple standby databases because all of the cell metrics relating to the standby databases are aggregated under one name.

  • If the role attribute is not specified, then the directive applies regardless of the database role.

  • For allocation-based resource management (using the level and allocation attributes), the sum of the allocation values (including OTHER) cannot exceed 100 for every combination of level and role.

  • The role attribute cannot be specified in DEFAULT or OTHER directives.

Example 7-55 Using the role Attribute with Allocation-Based Resource Management

CellCLI> ALTER IORMPLAN                                                     -
         dbplan=((name=sales_prod, level=1, allocation=30, role=primary),   -
                 (name=sales_prod, level=1, allocation=20, role=standby),   -
                 (name=sales2, level=1, allocation=20),                     -
                 (name=other, level=3, allocation = 50))

Example 7-56 Using the role Attribute with Share-Based Resource Allocation

CellCLI> ALTER IORMPLAN                                               -
         dbplan=((name=salesprod, share=4, role=primary),             -
                 (name=salesprod, share=1, limit=50, role=standby),   -
                 (name=finance, share=4),                             -
                 (name=hr, share=2))

Parent topic: ALTER IORMPLAN

7.7.1.7.25 type Attribute

Purpose

The type attribute enables you to create a profile, or template, to ease management and configuration of resource plans in environments with many databases.

Syntax

 ALTER IORMPLAN 
   dbplan=(( name=db_name, ... type={database|profile} ... ) ... )

Usage Notes

  • type: Specifies the directive type. Valid values are database or profile:

    • type=database: Specifies a directive that applies to a specific database. If type in not specified, then the directive defaults to the database type.

    • type=profile: Specifies a directive that applies to a profile rather than a specific database. To associate a database with an IORM profile, you must set the database initialization parameter db_performance_profile to the value of the profile name. Databases that map to a profile inherit the settings specified in the profile.

      A profile directive can contain any attributes except level, allocation, asmcluster, and role.

      A profile name cannot be OTHER or DEFAULT.

  • The dbplan can contain a combination of profile and database directives.

Example 7-57 Creating a Profile

This example shows how to specify profiles as part of a database plan.

CellCLI> ALTER IORMPLAN                                -
         dbplan=((name=gold, share=10, type=profile),  -
                 (name=silver, share=5, type=profile), -
                 (name=bronze, share=1, type=profile))

Parent topic: ALTER IORMPLAN

7.7.1.8 ALTER LUN

Purpose

The ALTER LUN command re-enables all LUNs or specified LUNs.

Syntax

ALTER LUN { ALL  | lun1 [ , lun2] ...  }
  REENABLE FORCE

Usage Notes

This command creates the cell disk and grid disk metadata on a replacement disk.

This command rebuilds redundancy for the system area of the system disks even when the system LUN is in a normal state.

Caution:

Data might be lost when using this command.

Example 7-58 Re-enabling a LUN

This example shows the ALTER command with the LUN object. 

CellCLI> ALTER LUN 'x:7' REENABLE FORCE

CellCLI> ALTER LUN ALL REENABLE FORCE

Parent topic: ALTER

7.7.1.9 ALTER METRICDEFINITION

Purpose

The ALTER METRICDEFINITION command controls the metrics that are included in the metric stream and in the fine-grained collection.

Syntax

ALTER METRICDEFINITION metric_name [, metric_name ]... attribute_name = attribute_value [, attribute_name = attribute_value]...
ALTER METRICDEFINITION attribute_name = attribute_value [, attribute_name = attribute_value]... attribute_filters

Usage Notes

  • In the command:

    • metric_name: Identifies a specific metric definition to alter.

    • attribute_filters: Identifies the metric definitions to alter by filtering according to attribute values.

    • attribute_name=attribute_value: Specifies an attribute setting:

      • The finegrained attribute controls whether the metric is enabled for fine-grained collection.

        Specify finegrained=enabled to enable the metric for fine-grained collection, or specify finegrained=disabled to disable fine-grained collection for the metric.

      • The streaming attribute controls whether the metric is included in the metric stream.

        Specify streaming=enabled to include the metric in the metric stream, or specify streaming=disabled to exclude the metric from the metric stream.

  • By default, a set of key performance metrics is automatically enabled for fine-grained collection and automatically included in the metric stream. However, you can customize the finegrained and streaming attributes independently. In other words, you can enable a metric for fine-grained collection without including it in the metric stream. Likewise, you can include a metric in the metric stream when it is not in the fine-grained collection.

  • To view the metrics enabled for fine-grained collection, use the LIST METRICDEFINITION command and examine the finegrained attribute value.

  • To view the metrics included in the metric stream, use the LIST METRICDEFINITION command and examine the streaming attribute value.

Example 7-59 Alter a Specific Metric Definition

This example shows the command to enable fine grained metric collection for the metric that shows the Ethernet network interface transfer rate (N_NIC_KB_TRANS_SEC). 

CellCLI> ALTER METRICDEFINITION N_NIC_KB_TRANS_SEC finegrained=enabled

Example 7-60 Alter a List of Metric Definitions

This example shows the command to disable fine grained metric collection for a listed set of metrics.

CellCLI> ALTER METRICDEFINITION N_MB_SENT,N_MB_RECEIVED finegrained=disabled

Example 7-61 Alter Metric Definitions Using a Filter

This example shows the command to include in the metric stream all of the metrics specified by the attribute filter.

CellCLI> ALTER METRICDEFINITION streaming=enabled WHERE name LIKE 'N_NIC.*'
7.7.1.10 ALTER OFFLOADGROUP

Purpose

The ALTER OFFLOADGROUP command enables you to alter modifiable attributes of offload groups, and also to restart, start up, and shut down services.

Syntax

ALTER OFFLOADGROUP { offloadgroup1 [,offloadgroup2, ...] }
{attribute_name = attribute_value [, attribute_name = attribute_value ...]]
| STARTUP | RESTART | SHUTDOWN }

Usage Notes

  • The offloadgroupN (where N is a number) parameters specify the names of the offload groups whose attributes you want to modify, or that you want to start, shut down, or restart.

  • The attribute_name and attribute_value parameters specify the name and value of the attribute you want to modify.

  • The STARTUP parameter specifies that the offload group(s) is to be started.

  • The RESTART parameter specifies that the offload group(s) is to be shut down, then started.

  • The SHUTDOWN parameter specifies that the offload group(s) is to be shut down.

Examples

Example 7-62 Updating the "Comment" Attribute

ALTER OFFLOADGROUP offloadgroup1 comment='System group'

Example 7-63 Starting up the Offload Group Named "offloadgroup1"

ALTER OFFLOADGROUP offloadgroup1 startup

Related Topics

Parent topic: ALTER

7.7.1.11 ALTER PHYSICALDISK

Purpose

The ALTER PHYSICALDISK command prepares a disk for replacement.

Syntax

ALTER PHYSICALDISK { ALL [ HARDDISK ] | disk_id1 [,disk_id2]  ...  }
 { DROP FOR REPLACEMENT [ MAINTAIN REDUNDANCY [ NOWAIT ] | FORCE ] | REENABLE }

Usage Notes

  • The DROP FOR REPLACEMENT option:

    • Is supported only for hot-pluggable disks

    • Checks if it is safe to proactively replace the specified disks. For example, if you attempt to drop the last good system disk, then replacing it would cause the system to crash.

    • If used without the MAINTAIN REDUNDANCY option, the DROP FOR REPLACEMENT option off-lines any data grid disks that exist on the physical disks.

    • Flushes the disk controller cache for physical disks based on hard disk drives

    • Prepares devices so that they can be removed online. For example, for flash devices this option powers off the associated PCIe slot.

  • The following options are available in conjunction with the DROP FOR REPLACEMENT option:

    • MAINTAIN REDUNDANCY maintains data redundancy by rebalancing data before dropping the corresponding ASM disks. Without this option, the specified grid disks are off-lined immediately, and data redundancy is affected until the physical disks are re-enabled.

    • In addition to the MAINTAIN REDUNDANCY option, NOWAIT allows the ALTER PHYSICALDISK command to complete immediately while the DROP FOR REPLACEMENT MAINTAIN REDUNDANCY operation runs asynchronously in the background.

    • FORCE ignores inbuilt safety checks and performs the command even if it is deemed unsafe. This option cannot be used in conjunction with the MAINTAIN REDUNDANCY option.

  • REENABLE re-enables a normal physical disk that was dropped for replacement.

  • SERVICELED is now obsolete. If you use this option, you will get the error message: CELL-04591.

Examples

Example 7-64 Dropping a Normal, Functioning Physical Disk

This example shows how to drop a physical disk.

CellCLI> ALTER PHYSICALDISK FLASH_5_1 DROP FOR REPLACEMENT

Example 7-65 Re-enabling a Physical Disk

This example shows how to re-enable a physical disk.

CellCLI> ALTER PHYSICALDISK 12:3 REENABLE

Related Topics

Parent topic: ALTER

7.7.1.12 ALTER PMEMCACHE

Purpose

The ALTER PMEMCACHE command can alter the set of cell disks used by PMEM cache, flush dirty blocks from PMEM cache, or cancel a previous flush operation on the specified cell disks to re-enable caching.

Note:

The ALTER PMEMCACHE command can only be used on Exadata X8M and X9M storage server models.

Syntax

ALTER PMEMCACHE { ALL | CELLDISK="cdisk1 [,cdisk2] ..." [FORCE]}}
      {FLUSH [NOWAIT] | CANCEL FLUSH}

Usage Notes

  • The ALL option affects all available PMEM cell disks.

  • The CELLDISK option allows you to specify individual cell disks. cdiskn represents a cell disk name.

  • The FLUSH option synchronizes dirty data from the PMEM cache to the cell disks. Dirty data is data that has been modified in the cache but not yet synchronized with the data on disk. Synchronization of dirty data can be a lengthy process, depending on the number of bytes to be synchronized. Use the following command to check the progress of the flush operation: 

    LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror

    Note:

    The FLUSH option stops new data from being cached on the PMEM cache until CELLSRV restarts, or the flush operation is canceled with the ALTER PMEMCACHE CANCEL FLUSH command.

  • The CANCEL FLUSH option terminates an earlier flush operation, and reinstates PMEM caching.

  • The NOWAIT option allows the ALTER command to complete while the flush operation is in progress.

  • The FORCE option can be used to forcefully change the set of cell disks used by the PMEM cache.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, you can interchangeably use ALTER XRMEMCACHE instead of ALTER PMEMCACHE.

Example 7-66 Using the ALTER PMEMCACHE Command

The following command specifies that the PMEM cache uses all PMEM cell disks. 

CellCLI> ALTER PMEMCACHE ALL

The following command specifies that the PMEM cache uses only two PMEM cell disks, ignoring any errors or warnings. 

CellCLI> ALTER PMEMCACHE CELLDISK='PM_01_mycell, PM_03_mycell' FORCE

The following command specifies initiates a flush operation for all PMEM cell disks, and returns the prompt before the operation completes. 

CellCLI> ALTER PMEMCACHE ALL FLUSH NOWAIT

Parent topic: ALTER

7.7.1.13 ALTER QUARANTINE

Purpose

The ALTER QUARANTINE command changes the attributes for a quarantine.

Syntax

ALTER QUARANTINE { ALL  | quarantine1 [,quarantine2]  ...  }
   attribute_name = attribute_value 
   [, attribute_name = attribute_value]...

Usage Notes

Only modifiable fields can be changed.

Examples

The following example shows the ALTER command with the QUARANTINE object.

Example 7-67 Altering a Quarantine

CELLCLI> ALTER QUARANTINE 12 comment='bugX'

Parent topic: ALTER

7.7.1.14 ALTER SOFTWAREUPDATE

Purpose

You can schedule software updates by setting SOFTWAREUPDATE attributes. The ALTER SOFTWAREUPDATE command enables you to alter modifiable Software Update attributes, to validate the pre-requirements for the software update, or to start the upgrade immediately.

You can also run the ALTER SOFTWAREUPDATE command using exacli.

Syntax

ALTER SOFTWAREUPDATE {VALIDATE PREREQ | UPGRADE [FORCE] | attribute = attribute value [,attribute = attribute value...]}

Options for the ALTER SOFTWAREUPDATE Command

  • VALIDATE PREREQ

    Run software update check pre-requirement steps now. This will download the software update pre-requirement code for the update specified by the store attribute. These checks are run automatically as part of update. Use this option only if you want to run prerequisite checks explicitly. Any error found will be displayed. A stateful alert will be raised if any error is found by the VALIDATE PREREQ command.

  • UPGRADE [FORCE]

    Run the software update (including the pre-requirement steps) now, using the software location specified by the Software Update store attribute. Use this command if you want to perform the update now rather than wait for the time specified by the Software Update time attribute.

    If FORCE is specified, then the upgrade continues despite any pre-requirement check errors.

  • attribute = attribute value

    Modify the specified Software Update attributes to the values provided.

Attributes for SOFTWAREUPDATE

The following attributes for the ALTER SOFTWAREUPDATE command are modifiable:

  • frequency: Storage server updates can automatically be done periodically by setting the frequency attribute to the desired frequency. You can specify one of the following values: {none | daily | weekly | biweekly }. If the value specified for frequency is '' or none, then the scheduled update is only done once. The value none can be used for the frequency in Oracle Exadata System Software release 19.1.0 or later.

  • name: The name of the patch to use in the update, which includes the software version string such as 18.1.1.0.0.171018. If you use the ALTER SOFTWAREUPDATE UPGRADE or ALTER SOFTWAREUPDATE VALIDATE PREREQ command, then the software store is checked and the name attribute is set automatically (if not already set) to the latest available version in the software store. Otherwise, the name attribute has a value of unknown. If there are multiple software versions at the store site, then this attribute can be used to specify which version should be used.

    Patches downloaded from My Oracle Support use a different name format, for example p26875767_181100_Linux-x86-64.zip. If you are using Oracle Exadata System Software 18c (18.1.0) or 18c (18.1.1), then you must rename the downloaded patch file so it has a name like 18.1.1.0.0.171018. Starting with Oracle Exadata System Software release 18.1.2, the ALTER SOFTWAREUPDATE command accepts patch names of the form p26875767_181100.

  • store: A URL for the location of the software store.

    If you specify a network store location using the HTTP or HTTPS protocol:

    • The URL must be accessible using the management network or RDMA Network Fabric.

    • MS automatically finds and downloads the required software update files.

    • The local staging location for the downloaded software update files is /root/swupdate or /var/swupdate.

    Alternatively, you can use the FILE protocol to specify a URL for a local store. When using a local store:

    • MS does not need to download the patch zip files or perform the associated space checks.

    • MS does not manage the local software store content. You must download the required patch files before patching and remove them afterward to free up space.

    • The file URL must use one of the following formats:

      • file:///localpath
      • file:/localpath

  • time: A future date and time at which the software update should be performed. The time can be specified as a local informal date and time, for example "1 AM, next Tuesday". If the date and time is valid then the output from setting this attribute shows the interpreted time in standard format with timezone offset, such as 2017-08-22T01:00:00-08:00.

    If you set this attribute to the empty string, "", then it cancels the scheduled software update.

  • timeLimitInMinutes: An update may wait for other storage servers to complete their updates in order to preserve disk group redundancy. By default, there is no limit on the amount of time which can be spent waiting to update. This attribute may be set to a positive, maximum integer which represents the number of minutes a storage server will spend waiting to update. If an update does not start within the time specified by the limit, then the update is canceled and an update alert is reported.

Usage Notes

  • The storage server software is initially updated on the unused system partition. Then, according to the desired schedule, the storage server activates the update by booting from the updated partition.
  • Software download and the prerequisite check will begin up to a week before the scheduled update time.
  • The update progress can be monitored by displaying the non-modifiable Software Update status attribute.
  • Software updates do not occur if the upgrade software is already installed
  • You can use dcli or exacli to schedule and install updates using the ALTER SOFTWAREUPDATE command.

  • The Software Update feature supports using HTTPS transport for software downloads. When using HTTPS, TLS certificate checks are performed by default. If the remote server’s certificate cannot be validated then the following error is reported:

    CELL-00076: An error occurred during download of software update:
source https://hostname:port is not available.
CELL-00092: The store's TLS certificate cannot be authenticated with known CA certificates.

    This can happen if the remote server uses a self-signed certificate or if the remote server uses a certificate signed by a certificate authority (CA) that is not included in the storage server’s CA store. You can use the following procedure to add a CA certificate to the storage server’s CA store. This is a security setup step which requires shell access as root on the storage server.

    1. Get a CA certificate that can verify the remote server. The certificate should be stored in PEM or DER file format.
    2. Copy the file to the storage server at this directory: /etc/pki/ca-trust/source/anchors/
    3. Run following commands:
      update-ca-trust enable

update-ca-trust extract

    Use the operating system man utility to get more information about the update-ca-trust command.

Examples

Example 7-68 Modifying the Software Update time Attribute

Modify the scheduled time of the next software update to 1 a.m. on Thursday.

CellCLI> ALTER SOFTWAREUPDATE time = "1 AM Thursday"
CELL update is scheduled to begin at 2017-08-24T01:00:00-08:00

Example 7-69 Setting the Software Update store Attribute

This example shows how to set the store attribute to a location that uses HTTPS protocol.

ALTER SOFTWAREUPDATE store="https://my-exa-store/cell"

Example 7-70 Starting a Software Update Immediately

This example shows how to immediately start a software update using the attribute values already specified.

ALTER SOFTWAREUPDATE UPGRADE FORCE

Parent topic: ALTER

7.7.1.15 ALTER THRESHOLD

Purpose

The ALTER THRESHOLD command updates the attribute values of all thresholds or the specified thresholds.

Syntax

ALTER THRESHOLD { ALL |threshold_name [, threshold_name ...] }
   attribute_name = attribute_value 
   [, attribute_name = attribute_value]...

Usage Notes

The attributes that can be changed with the ALTER command are shown as modifiable in Describing the THRESHOLD Object.

Examples

The following example shows how to alter threshold attributes.

Example 7-71 Altering Threshold Attributes

CellCLI> ALTER THRESHOLD ct_io_wt_rq.interactive warning=10, critical=20, -
                comparison='=', occurrences=2, observation=10

CellCLI> ALTER THRESHOLD ALL occurrences=3

Related Topics

Parent topic: ALTER

7.7.1.16 ALTER USER

Purpose

The ALTER USER command changes the attributes of a user role.

Syntax

ALTER USER user1 attribute_name1 = attribute_value1      \
[, attribute_name2 = attribute_value2, ...]

Usage Notes

  • The user name cannot be root, celladmin or cellmonitor. Those are reserved.

  • The user name should be unique.

  • The system prompts for a password for the new user. The password must have 12 to 40 alphanumeric characters or special characters !@#$%^&*() with at least one digit, one lowercase letter, and one uppercase letter. Starting with Oracle Exadata System Software release 18.1.0.0.0, the password can be 8 to 40 characters in length and can also utilize the special characters - and _.

  • The new password cannot be the same as the current password for the user.

Example 7-72 Using the ALTER USER Command

This example shows how to change a user's password.

CellCLI> ALTER USER sjones password=TOPsecret2345

Parent topic: ALTER

7.7.1.17 ALTER XRMEMCACHE

Purpose

Starting with Oracle Exadata System Software release 23.1.0, the ALTER XRMEMCACHE command is equivalent to the ALTER PMEMCACHE command.

Note:

The ALTER XRMEMCACHE command can only be used on Exadata X8M and X9M storage server models.

Parent topic: ALTER

7.7.2 ASSIGN KEY

Purpose

The ASSIGN KEY command assigns or removes a security key to or from a client.

Syntax

ASSIGN KEY FOR [ASMCLUSTER] 'client_name1' = 'key-value1' [, 'client_name2' = 'key-value2'...]

ASSIGN KEY FOR CELL 'key-value'

ASSIGN KEY FOR [REMOTE | LOCAL] CELL 'client_name1' = 'key-value1' [, 'client_name2' = 'key-value2'...]

Options

  • client_name is an alias that is the unique name (DB_UNIQUE_NAME) for a database client or Oracle ASM cluster.

    Note:

    The client name or Oracle ASM cluster name not case-sensitive. For example, ASM1 and asm1 are treated as the same value.

  • key-value is a hexadecimal string key that is assigned to the client as a security key. The key value is generated with the CREATE KEY command. The key values assigned with the ASSIGN command must match the key in the client cellkey.ora file on the database servers. The key value can be the same for multiple clients that need the same access. An empty string for the key-value removes a previously assigned key.

  • Starting with Oracle Exadata System Software release 12.2.1.1.0, you can use the optional keyword ASMCLUSTER to indicate that the client is an Oracle ASM cluster. The Oracle ASM cluster alias must not be longer than 14 characters, and only alphanumeric and hyphen characters are allowed.

  • Starting with Oracle Exadata System Software release 12.2.1.1.0, the use of the CELL keyword can be used to assign a single key to all storage servers to enable cell-to-cell direct operations. You specify only a single key-value; you do not specify a client_name. You cannot use a list of values with the CELL keyword.

  • Starting with Oracle Exadata System Software release 12.2.1.1.0, the FOR LOCAL CELL clause assigns a cell key to the local (current) cell. If you specify FOR LOCAL CELL, there can be only one key; a list of values is not supported. The client_name is a unique identifier for each cell.

  • Starting with Oracle Exadata System Software release 12.2.1.1.0, the FOR REMOTE CELL clause specifies the cell keys that the current cell will accept. The client_name is the unique identifier for the cell assigned the key-value. You can specify a single client and key, or a list of values.

Usage Notes

  • For ASM-scoped security or DB-scoped security, the client aliases must be entered in the availableTo attribute of the GRIDDISK object.

  • When using the ASMCLUSTER keyword in Oracle Exadata System Software release 12.2.1.1.0 or later, if you specify a client name and key that already exists (that is a key was already specified for an Oracle ASM client prior to Oracle Exadata System Software release 12.2.1.1.0), then the client will be changed to be an Oracle ASM cluster client. In this case, the name and key will be removed from the ASM-scoped security list, and added as an Oracle ASM cluster client. Grid disks with this Oracle ASM client in their ACL can remain online for this operation.

Examples

Example 7-73 Assigning Keys to Clients

This example shows how to use the ASSIGN KEY command to assign keys to one or multiple clients. 

CellCLI> ASSIGN KEY FOR 'db0' ='b67d5587fe728118af47c57ab8da650a'

CellCLI> ASSIGN KEY FOR '+asm'='7c57ab8da650ab118587feaf467d5728'

CellCLI> ASSIGN KEY FOR '+asm'='ed63f41779c262ddd34a00c0d83590b8',  -
                         'db1' ='118af47c57ab8da650ab67d5587fe728',  -
                         'db2' ='8a65313e8de6cd8bcbab7f4bdddb0498',  -
                         'db3' ='9140c767bd92d1b45783e7fe6520e6d'


CellCLI> ASSIGN KEY FOR LOCAL CELL mykey='fa292e11b31b210c4b7a24c5f1bb4d32'

CellCLI> ASSIGN KEY FOR REMOTE CELL -
          'cellkey1'='b67d5587fe728118af47c57ab8da650a', -
          'cellkey2'='118af47c57ab8da650ab67d5587fe728'


CellCLI> ASSIGN KEY FOR CELL '4839deff903625aab394df7638e7b29a'

CellCLI> ASSIGN KEY FOR ASMCLUSTER asm1='118af47c57ab8da650ab67d5587fe728'

Example 7-74 Removing Keys from Clients

This example shows how to use the ASSIGN KEY command to remove keys from clients. 

CellCLI> ASSIGN KEY FOR 'db1'='', 'db2'='', 'db3'='', '+asm'=''

CellCLI> ASSIGN KEY FOR ASMCLUSTER asm1=''

Related Topics

Parent topic: CellCLI Command Reference

7.7.3 CALIBRATE

Purpose

The CALIBRATE command runs raw performance tests on cell disks, enabling you to verify the disk performance before the cell is put online.

Syntax

CALIBRATE [FLASHDISK | HARDDISK | LUN1 [, LUN2]] [FORCE]

Usage Notes

You must be logged on to the cell as the root user to run CALIBRATE.

The FORCE option enables you to run the tests when Cell Server is running. If you do not use the FORCE option, then Cell Server must be shut down. Running CALIBRATE at the same time as a Cell Server process impacts performance.

Use the FLASHDISK option to specify that only flash LUNs be calibrated.

Use the HARDDISK option to specify that only hard disk LUNs be calibrated.

Use the LUNn option to specify a list of LUNs by name be calibrated.

Examples

Example 7-75 Output from CALIBRATE Command with FORCE Option on Oracle Exadata Storage Server

This example shows the output when using CALIBRATE with FORCE option on Oracle Exadata Storage Server. 

CellCLI> CALIBRATE FORCE
Calibration will take a few minutes...
Aggregate random read throughput across all hard disk luns: 1604 MBPS
Aggregate random read throughput across all flash disk luns: 4242.9 MBPS
Aggregate random read IOs per second (IOPS) across all hard disk luns: 4927
Aggregate random read IOs per second (IOPS) across all flash disk luns: 148695
Controller read throughput: 1608.05 MBPS
Calibrating hard disks (read only) ...
Lun 0_0  on drive [20:0      ] random read throughput: 153.41 MBPS, and 412 IOPS
Lun 0_1  on drive [20:1      ] random read throughput: 155.38 MBPS, and 407 IOPS
Lun 0_10 on drive [20:10     ] random read throughput: 155.32 MBPS, and 423 IOPS
Lun 0_11 on drive [20:11     ] random read throughput: 151.24 MBPS, and 427 IOPS
Lun 0_2  on drive [20:2      ] random read throughput: 152.70 MBPS, and 422 IOPS
Lun 0_3  on drive [20:3      ] random read throughput: 155.42 MBPS, and 423 IOPS
Lun 0_4  on drive [20:4      ] random read throughput: 153.14 MBPS, and 428 IOPS
Lun 0_5  on drive [20:5      ] random read throughput: 154.06 MBPS, and 424 IOPS
Lun 0_6  on drive [20:6      ] random read throughput: 150.82 MBPS, and 409 IOPS
Lun 0_7  on drive [20:7      ] random read throughput: 154.61 MBPS, and 426 IOPS
Lun 0_8  on drive [20:8      ] random read throughput: 154.46 MBPS, and 424 IOPS
Lun 0_9  on drive [20:9      ] random read throughput: 154.63 MBPS, and 426 IOPS
Calibrating flash disks (read only, note that writes will be significantly slower) ...
Lun 1_0  on drive [[10:0:0:0]] random read throughput: 269.11 MBPS, and 19635 IOPS
Lun 1_1  on drive [[10:0:1:0]] random read throughput: 268.86 MBPS, and 19648 IOPS
Lun 1_2  on drive [[10:0:2:0]] random read throughput: 268.68 MBPS, and 19645 IOPS
Lun 1_3  on drive [[10:0:3:0]] random read throughput: 268.92 MBPS, and 19640 IOPS
Lun 2_0  on drive [[12:0:0:0]] random read throughput: 269.78 MBPS, and 20436 IOPS
Lun 2_1  on drive [[12:0:1:0]] random read throughput: 269.69 MBPS, and 20394 IOPS
Lun 2_2  on drive [[12:0:2:0]] random read throughput: 269.04 MBPS, and 20439 IOPS
Lun 2_3  on drive [[12:0:3:0]] random read throughput: 269.51 MBPS, and 20420 IOPS
Lun 4_0  on drive [[9:0:0:0] ] random read throughput: 269.07 MBPS, and 19668 IOPS
Lun 4_1  on drive [[9:0:1:0] ] random read throughput: 269.24 MBPS, and 19697 IOPS
Lun 4_2  on drive [[9:0:2:0] ] random read throughput: 269.09 MBPS, and 19676 IOPS
Lun 4_3  on drive [[9:0:3:0] ] random read throughput: 269.03 MBPS, and 19681 IOPS
Lun 5_0  on drive [[11:0:0:0]] random read throughput: 268.06 MBPS, and 19714 IOPS
Lun 5_1  on drive [[11:0:1:0]] random read throughput: 268.24 MBPS, and 19696 IOPS
Lun 5_2  on drive [[11:0:2:0]] random read throughput: 268.33 MBPS, and 19717 IOPS
Lun 5_3  on drive [[11:0:3:0]] random read throughput: 268.14 MBPS, and 19693 IOPS
CALIBRATE results are within an acceptable range.
 
CALIBRATE stress test is now running...
Calibration has finished.

Example 7-76 Calibrating LUNs by Name

CALIBRATE '2_1', '2_3' FORCE

Related Topics

Parent topic: CellCLI Command Reference

7.7.4 CREATE

Purpose

The CREATE command creates a new object and assigns initial attributes to the object.

Syntax

CREATE object_type [name] ... 
   [attribute_name = attribute_value [, attribute_name = attribute_value]...]

Usage Notes

  • When multiple objects are valid as the target of a CREATE command, there is the possibility of partial success. If an error occurs, then the command is interrupted, and the remaining objects are not created.

Related Topics

Parent topic: CellCLI Command Reference

7.7.4.1 CREATE CELL

Purpose

The CREATE CELL command creates a cell object and assigns initial attributes to the object.

Syntax

CREATE CELL [name]
   [ interconnect1=intValue1 ] [, interconnect2=intValue2 ...]
   [, attributeName = attributeValue  ...]

Usage Notes

The attributes that can be set are shown as modifiable in Example 7-97.

  • This command can be used to assign the ASR value to the snmpSubscriber attribute.

    When specifying the snmpSubscriber attribute, the community name cannot contain spaces or the following characters: = ' " \ / < >

  • The default cell name is set to the network host name of the cell with hyphens in the network name replaced with underscores. You can display the network name with the uname -n command. If you change the cell name, then you must choose a unique cell name.

  • One to four interconnects can be specified. The interconnect1 attribute must be specified if the interconnect2 attribute is specified. The interconnect1 and interconnect2 attributes must be specified if interconnect3 is specified, and so on.

  • By default, the CREATE CELL command creates Exadata Smart Flash Cache and the associated cell disks.

    You can specify FLASHCACHE=0 to bypass default creation of Exadata Smart Flash Cache. A non-zero value specifies the total size for creating Exadata Smart Flash Cache. The size is divided evenly across the flash LUNs.

  • By default, the CREATE CELL command creates Exadata Smart Flash Log and the associated cell disks.

    You can specify FLASHLOG=0 to bypass default creation of Exadata Smart Flash Log. A non-zero value specifies the total size for creating Exadata Smart Flash Log. The size is divided evenly across the flash LUNs.

  • On Exadata X8M and X9M storage server models that are equipped with Persistent Memory (PMEM), the CREATE CELL command automatically creates PMEM cache, PMEM log, and the associated cell disks.

    Note:

    Oracle Exadata System Software release 23.1.0 introduces Exadata RDMA Memory (XRMEM). XRMEM represents the collection of Exadata software technologies that provide direct access to storage server memory using Remote Direct Memory Access (RDMA), enabling faster response times and lower read latencies. In this release, the persistent memory data accelerator, previously known as PMEM cache, is now called XRMEM cache. Likewise, the persistent memory commit accelerator, previously known as PMEM log, is now called XRMEM Log.

  • Starting with Exadata X10M, on storage server models equipped to support Exadata RDMA Memory Cache (XRMEM cache), the CREATE CELL command automatically creates the XRMEM cache.

  • The CREATE CELL eighthRack command enables or disables an Eighth Rack configuration on Oracle Exadata Database Machine X3-2 Quarter Racks or later. The options are true to enable the Eighth Rack configuration, and false to disable the Eighth Rack configuration. The CREATE CELL eighthRack=true command requires that there are no cell disks because enabling the Eighth Rack configures only half of the hard disks and flash capacity.

  • The CREATE CELL flashCacheCompress command creates a cell with or without flash cache compression. Flash cache compression maximizes the amount of data in cache, and improves the cache hit rate. The options are true to create a cell with flash cache compression enabled, and false to create a cell without flash cache compression. The system must be restarted in order to change flash cache compression.

    Note:

    Flash cache compression is only supported on Oracle Exadata Database Machine X3 or Oracle Exadata Database Machine X4 racks

  • Starting with Oracle Exadata System Software release 19.1.0, the httpsAccess attribute can be used to specify a list of IP addresses or IP subnet masks that control who can access the RESTful service via HTTPs. The value you specify for httpsAccess overwrites any previous value. You can use the following values for httpsAccess:

    • ALL — to allow access to all hosts (Default)
    • NONE — to disable the HTTPs port completely
    • IP1, IP2,..., IPn — to only allow access to hosts with IP addresses IP1, IP2,..., IPn where IPn is a valid IP address in IPv4, IPv4 subnet, IPv6 or IPv4-embedded IPv6 format. You can specify a maximum of 512 IP addresses for the access control list.

    Additionally, instead of a single IP address, you can use the / character to specify a range of IP addresses using a subnet mask. For example the range '192.168.10.0/24' corresponds to hosts having IP addresses from 192.168.10.1 to 192.168.10.255. If you specify an IP address range, you need to enclose the IP address string in quotes.

Examples

Example 7-77 Creating a Cell

This example shows how to create a cell. In the example, the interconnections are set to an existing InfiniBand Network Fabric connection. 

CellCLI> CREATE CELL cell22 interconnect1=bondib0

Example 7-78 Creating an Eighth Rack Configuration

This example shows how to create a cell in an Eighth Rack configuration. 

CellCLI> CREATE CELL eighthRack=true

Example 7-79 Creating a Cell with Restricted HTTPs Access

This example shows how to create a cell that allows HTTPs port access only from hosts having IP addresses in the range 192.168.10.1 to 192.168.10.255.

CellCLI> CREATE CELL httpsAccess='192.168.10.0/24'
7.7.4.2 CREATE CELLDISK

Purpose

The CREATE CELLDISK command creates a cell disk object and assigns initial attributes to the object. You can use the ALL option to automatically create cell disks.

Syntax

CREATE CELLDISK  {  
   ALL [FLASHDISK | HARDDISK] 
  |cdisk1 attribute_name=value,[attribute_name=value]... [FORCE]
  |((name=cdisk2,attribute_name=value,[attribute_name=value]...)
  [,(name=cdisk3,attributename=value,[attributename=value]...)]...)
  }

Usage Notes

The attributes that can be specified during creation are the cell disk name (cdiskN), comment, lun, size, and physicalDisk.

  • Either lun or physicalDisk is required when adding a specifically-named cell disk.

    • When a physical disk is provided, a single-disk LUN is created, and that LUN is used to create the cell disk. The LUN is flagged as automatically-created.

    • When a LUN is provided, that device is used to create the cell disk.

  • You can use the size attribute when adding a new disk that is a different size than the existing disks. You must specify a value for size that is less than or equal to the maximum allowed cell disk size.

  • CREATE CELLDISK ALL is a shortcut command to create all candidate cell disks for the cell. This operation occurs in two steps:

    • All physical disks that are not already configured as LUNs are configured as single-disk LUNs (SDLs). These LUNs are flagged as automatically-created LUNs.

    • All LUNs that are not configured as cell disks are used to create cell disks. These cell disks are initially named according to the template CD_lunname_cellname. This name can later be changed using the ALTER CELLDISK command.

      Note:

      LUNs with a second or third extended file system (ext2/ext3) are ignored during the CREATE CELLDISK ALL operation.

    • You can include size to create all cell disks with the specified size, instead of attempting to use the entire disk. If you do not specify size with the CREATE CELLDISK ALL command, then:

      • On disks without a partition containing the Exadata System Software, Management Server (MS) creates the cell disks with a size that is equal to the smallest physical disk size in the cell (which is also the maximum cell disk size allowed in the cell).
      • On disks containing a system partition, MS creates the cell disk with a size that is equal to the maximum allowed cell disk size minus the size of the system partition.
  • The FLASHDISK option limits the CREATE CELLDISK command to cell disks that are flash disks.
  • The HARDDISK option limits the CREATE CELLDISK command to cell disks that are hard disks.
  • The list form of CREATE CELLDISK enables you to add a series of cell disks in a single command.
  • The FORCE keyword overrides the following error conditions:
    • The physical disk provided is already part of an existing LUN.
    • The LUN provided is already associated with a cell disk.

    FORCE causes the LUN to be reused to create the new cell disk. Any preexisting configuration is lost. FORCE is not an option for CREATE CELLDISK ALL or for the list form of CREATE CELLDISK.

  • The INTERLEAVING option has been deprecated. Starting with Oracle Exadata System Software release 19.1.0, attempts to create interleaving grid disks will be automatically converted to normal grid disk creation. Interleaving grid disks created in earlier Oracle Exadata System Software releases will continue to operate normally.

Cell disks are created automatically using the CREATE CELLDISK ALL command. This command creates single-disk LUNs from all available physical disks, and then creates cell disks from all available LUNs.

When a cell disk is created, metadata describing the cell disk is written to the cell disk itself and to the cell configuration files. Approximately 48 MB of the cell disk is allocated for the cell disk metadata partition. On a subsequent restart, Cell Server (CELLSRV) attempts to rediscover the created cell disk by reading configuration data on the disk. Any hardware changes in the cell might cause a change in the LUN and device name for a cell disk. The rediscovery mechanism that runs during the cell restart process changes the cell disk configuration accordingly.

Example 7-80 Creating a Cell Disk

CellCLI> CREATE CELLDISK ALL

CellCLI> CREATE CELLDISK cdisk03 lun=0_3

CellCLI> CREATE CELLDISK cdisk04 physicalDisk='I2:1:2'
CellCLI> CREATE CELLDISK CD_08_cell06 lun=0_8, size=300M

CellCLI> CREATE CELLDISK CD_03_cell04 lun=0_3

CellCLI> CREATE CELLDISK CD_05_cell09 physicalDisk='2I:1:2'
7.7.4.3 CREATE DIAGPACK

Purpose

The CREATE DIAGPACK command creates a diagnostic package, which contains logs and traces that you can use to troubleshoot problems in your system. You can also send the generated package to Oracle Support Services, as needed.

Syntax

CREATE DIAGPACK packStartTime=time, [durationInHrs=duration]

or

CREATE DIAGPACK alertName=alertName

Usage Notes

When an alert occurs, a diagnostic package is created automatically. This package contains logs and traces related to the alert.

The CREATE DIAGPACK command enables you to generate diagnostic packages manually.

  • The packStartTime parameter specifies when to start collecting the logs and traces. The format of packStartTime is yyyy_MM_ddTHH_mm_ss, For example: 2015_07_07T09_00_00.

    You can also specify the keyword nowfor packStartTime. The packStartTime cannot be in the future and cannot be older than 7 days. The value of packStartTime is used as part of the name of the diagnostic package.

  • The durationInHrs parameter specifies the number of hours of logs and traces to include in the diagnostic package. Valid values are from 1 (default) to 6.

    Every diagnostic package includes logs 1 hour before and 1 hour after the packStartTime. For example, if you specify a time of 12_00_00, then logs will collected from 11_00_00 to 13_00_00, unless the end time is in the future.

  • The alertName parameter specifies the alert name for which to create the diagnostic package. You can run the LIST ALERTHISTORY command to view the alert names.

Name of Diagnostic Packages

The name of the diagnostic package is formed as: hostname_diag_packStartTime_unique package ID

For example: testcell1_diag_2015_07_07T09_00_00_3

For alerts, the name of the diagnostic package is formed as: hostname_timestamp of when the package was created_alert ID. For example: testcell1_2015_09_30T13_13_00_2_1

Location of Diagnostic Packages

The location of the diagnostic packages is $LOG_HOME.

Status of Diagnostic Packages

You can run the LIST DIAGPACK command to get a list of diagnostic packages in your system, and their status.

Privileges Needed to Create, List, and Download Diagnostic Packages

There are certain privileges that are needed for working with diagnostic packages. Use CellCLI to grant the following privileges to a role:

  • Privilege to create diagnostic packages:

    grant privilege CREATE ON DIAGPACK to ROLE role

  • Privilege to list diagnostic packages and check their status:

    grant privilege LIST ON DIAGPACK to ROLE role

  • Privilege to download diagnostic packages:

    grant privilege DOWNLOAD ON DIAGPACK to ROLE role

You can then grant the role to users. For example, if you named your role diagpack_role, the following command grants the role to fred. 

CellCLI> GRANT ROLE diagpack_role TO USER fred

During deployment, Oracle Exadata Deployment Assistant (OEDA) creates an Exadata storage software user called CELLDIAG. You can use this user to connect to a cell remotely using ExaCLI or REST API. This user has privileges to create, list, and download diagnostic packages.

Downloading Diagnostic Packages

You can download diagnostic packages using any of the following methods. Note that you need the DOWNLOAD ON DIAGPACK privilege before you can download diagnostic packages.

  • Using the REST API

    • To download the diagnostic package by name, use the following URL, where hostname specifies the host name of the cell and diagpackname specifies the name of the diagnostic package: 
      https://hostname/diagpack/download?name=diagpackname

      If the user is not already logged in, the URL will prompt for a user name and password.

      Diagnostic packages can also be accessed at https://hostname/diagpack . For example: https://cell1.example.com/diagpack.

      The page then prompts the user to log in:

      User: fred
Password: ********

      Based on the user's privileges, various sections of this page could be hidden:

      • The form to create a new diagpack will not be shown if the user does not have the CREATE ON DIAGPACK privilege.

      • Similarly, the list of alerts and their diagnostic packages will not be shown if the user does not have the LIST ON DIAGPACK privilege.

    • To download the diagnostic package by alert name, use the following URL, where hostname specifies the host name of the cell and alertName specifies the alert name of the diagnostic package: 

      https://hostname/diagpack/download?alert=alertName

      The alert name is the same alert name that is used in AlertHistory. It looks like 1, 2, 3 for stateless alerts, and 1_1, 2_1, 3_1, 3_2 for stateful alerts.

  • Using the download ExaCLI command

    ExaCLI enables you to run CellCLI commands on storage nodes remotely from compute nodes.

    To run the download command, run the following commands on a compute node:

    1. Start up ExaCLI and connect to the cell containing the diagnostic pack. For example, use a command similar to the following where hostname specifies the host name of the cell: 

      exacli -l celladministrator -c hostname
Password=********

    2. Run the download command using a command similar to the following where name specifies the name of the diagnostic package to download and destinationFolder specifies the directory where you want to save the downloaded diagnostic package: 

      exacli> download diagpack name destinationFolder

  • Getting the diagnostic package from the alert emails

    The alert emails include diagnostic packages for all alerts except INFO, CLEAR, and WARNING. Diagnostic packages are generated for critical alerts only.

Re-triggering Package Creation from the Web Page

You can use the following URL to re-trigger package creation:

https://hostname/diagpack

If the diagnostic package for an alert does not exist on disk, then the web page shows a Create Package link instead of a Download link.

Click the Create Package link to add the alert to the list for creating a diagnostic package. Once the diagnostic package has been created, and the web page is refreshed, the page will display a Download link that you can use to download the newly created diagnostic package.

Turning Off the Diagnostic Pack Attachment in Emails

To turn off the diagnostic pack attachment in emails, run ALTER CELL diagPackEmailAttach=FALSE. The diagnostic packs are still generated and stored on the storage servers. To download the diagnostic packs, see "Downloading Diagnostic Packages".

Examples

Example 7-81 Using "now" for packStartTime

This example creates a diagnostic package using now as the start time and the default duration of 1 hour.

The output is 1 compressed file under $LOG_HOME. 

CellCLI> CREATE DIAGPACK packStartTime="now"
    Processing: scab01cel11_diag_2015_07_08T17_53_58_1
    Use 'list diagPack' to check its status.

Example 7-82 Specifying a duration

This example creates 3 diagnostic packages under $LOG_HOME:

The first package has a start time of 2015_07_07T09_00_00.

The second package has a start time of 2015_07_07T10_00_00.

The third package has a start time of 2015_07_07T11_00_00. 

CellCLI> CREATE DIAGPACK packStartTime="2015_07_07T09_00_00", durationInHrs=3
    Processing: scab01cel11_diag_2015_07_07T09_00_00_1
    scab01cel11_diag_2015_07_07T10_00_00_1 (In queue...)
    scab01cel11_diag_2015_07_07T11_00_00_1 (In queue...)
    Use 'list diagPack' to check its status.
7.7.4.4 CREATE FLASHCACHE

Purpose

The CREATE FLASHCACHE command creates Exadata Smart Flash Cache on a cell for I/O requests.

Syntax

CREATE FLASHCACHE { ALL [size=fc_size] | CELLDISK="cdisk1 [,cdisk2] ..." [, size=fc_size] }

Usage Notes

Cell disks defined on Exadata Smart Flash Cache cannot be exported.

The ALL argument creates Exadata Smart Flash Cache on all flash cell disks. If the ALL argument is not specified, then the CELLDISK argument must be specified.

Using the CELLDISK argument, you can specify a list of flash cell disks to be used for flash cache. The names of the flash cell disks are comma-delimited. The FLASHDISK argument is not required.

The size argument specifies the total space used for flash cache. Similar to space in grid disks and flash logs, flash cache space is allocated in 16 MB units, referred to as allocation units. If the size attribute is specified when creating a flash cache, then the size allocated is the size of the largest multiple of allocation units less than or equal to the specified size. For example, if 300M is specified for the size attribute, then 288 MB (16x18) is allocated because 288 is the largest multiple of 16 that is less than or equal to 300.

A minimum of 1 allocation unit is always allocated, so the minimum size for a flash cache is 16 MB. Any size value less than 16 MB is rounded up to 16 MB.

Before specifying the size attribute, ensure that you have first determined the available free space on each target flash cell disk with the LIST FLASHCACHE command. For example, LIST FLASHCACHE ATTRIBUTES freespace. If the size attribute is not specified, then the maximum size is allocated.

If the size attribute is not specified, then all available space on each cell disk in the list is used for Exadata Smart Flash Cache.

By default, 5 percent of space on Extreme Flash storage servers is used for write-back flash cache.

Examples

Example 7-83 Creating Exadata Smart Flash Cache

This example shows how to create Exadata Smart Flash Cache on a cell.

CellCLI> CREATE FLASHCACHE ALL

CellCLI> CREATE FLASHCACHE ALL SIZE=250g

CellCLI> CREATE FLASHCACHE CELLDISK='fd_01,fd_02,fd_03,fd_04'

CellCLI> CREATE FLASHCACHE CELLDISK='fd_01_mycell,fd_02_mycell', size = 64G

Related Topics

Parent topic: CREATE

7.7.4.5 CREATE FLASHLOG

Purpose

The CREATE FLASHLOG command creates the Oracle Exadata Smart Flash Log on a cell for redo log write requests.

Syntax

CREATE FLASHLOG { ALL [ FLASHDISK ] [ size=log_size ] | 
          CELLDISK='cdisk1[,cdisk2]...' [ , size=log_size ] }

Usage Notes

The CREATE FLASHLOG command accepts a list of comma-delimited flash cell disks. If a size is specified in the command, then that size is divided evenly across the cell disks, and will total the specified size. If a size is not specified, then a default size of 512 MB is used.

The size of Oracle Exadata Smart Flash Log space on each flash disk must be less than 4 GB. If all 16 flash disks are available, then the total size of Oracle Exadata Smart Flash Log must be less than 64 GB.

Similar to space in grid disks and flash cache, flash log space is allocated in 16 MB units, referred to as allocation units. If the size attribute is specified when creating a flash log, then the size allocated is the size of the largest multiple of allocation units less than or equal to the specified size. For example, if 300M is specified for the size attribute, then 288 MB (16x18) is allocated because 288 is the largest multiple of 16 that is less than or equal to 300.

A minimum of 1 allocation unit is always allocated, so the minimum size for a flash log is 16 MB. Any size value less than 16 MB is rounded up to 16 MB.

The ALL FLASHDISK argument creates Oracle Exadata Smart Flash Log on all flash cell disks. If the ALL argument is not specified, then the CELLDISK argument must be specified. The FLASHDISK argument is not required.

Note:

The CREATE FLASHCACHE command, by default, uses all available space on each flash disk. Therefore, use the CREATE FLASHLOG command before creating the flash cache to ensure both objects consume the correct amount of flash disk space.

To change the size of the flash log, use the DROP FLASHLOG command to drop the flash log, and then use the CREATE FLASHLOG command to create a flash log with the new size.

Examples

The following example shows how to create Oracle Exadata Smart Flash Log on a cell.

Example 7-84 Creating Oracle Exadata Smart Flash Log

CellCLI> CREATE FLASHLOG ALL

CellCLI> CREATE FLASHLOG ALL SIZE=1g

CellCLI> CREATE FLASHLOG ALL FLASHDISK

CellCLI> CREATE FLASHLOG CELLDISK='fd1,fd2,fd3,fd4'

Parent topic: CREATE

7.7.4.6 CREATE GRIDDISK

Purpose

The CREATE GRIDDISK command creates a grid disk object on a specified cell disk or creates one or more grid disks on each cell disk in the storage server. The command also assigns initial attributes to each new grid disk.

Syntax

CREATE GRIDDISK  
   { ALL [ FLASHDISK | HARDDISK ] PREFIX={[']gdisk_name_prefix[']|'gdisk_name_prefix1[,gdisk_name_prefix2]...'}
      [,multi_attribute_name={[']attribute_value[']|'attribute_value1[,attribute_value2]...'} ]...
   | gdisk_name CELLDISK=cell_disk_name }
   [,attribute_name=[']attribute_value[']]...

Usage Notes

  • If an individual grid disk name (gdisk_name) is specified, then the grid disk is created on the cell disk specified by the CELLDISK argument. You must ensure that the grid disk name is unique across all storage servers. If the disk name is not unique, then it might not be possible to add the grid disk to an Oracle ASM disk group.

  • The length of a grid disk name is limited to 30 characters.

  • If the ALL option is specified without FLASHDISK or HARDDISK, then the command creates grid disks on all available cell disks.

    If the ALL option is specified with FLASHDISK or HARDDISK, then the command only creates grid disks on cell disks associated with the specified media type.

  • The PREFIX option must be specified when ALL is used.

    The PREFIX option specifies one or more comma-separated prefix strings. Each prefix is used to create a grid disk on the underlying cell disk. The generated grid disk names are composed of the grid disk prefix followed by an underscore (_) and then the cell disk name.

    For example, CREATE GRIDDISK ALL PREFIX=data01 creates one grid disk on each available cell disk. In this case, if the cell disks are named CD_01_cell01, CD_02_cell01, CD_03_cell01, and so on, then the corresponding grid disk names are data01_CD_01_cell01, data01_CD_02_cell01, data01_CD_03_cell01, and so on.

    Use prefixes that match the Oracle ASM disk groups that consume the grid disks. This helps you to identify where the grid disks are being used. Also, use short prefix values to ensure that the generated grid disk names stay within the 30-character limit.

  • multi_attribute_name specifies one of the following attributes, which may accept a comma-separated list of values:

    • size

    • offset

    • virtualSize

    • comment

    If the command specifies multiple comma-separated PREFIX values, then for each multi_attribute_name you must specify only one value or the same number of values as in the prefix list. If one value is specified, it applies to all values in the prefix list. Otherwise, each entry in the list of attribute values applies to the corresponding value in the prefix list.

    For example, CREATE GRIDDISK ALL PREFIX='data01,data02', size='500G,300G' creates two grid disks on each available cell disk. In this case, size=500G is associated with PREFIX=data01, and size=300G is associated with PREFIX=data02.

    All other attribute settings require only one value at all times.

  • The size attribute determines the amount of storage space that is allocated to the grid disk. If the size attribute is not specified, then the grid disk consumes all of the available space on the cell disk.

    Grid disk space is allocated in 16 MB units, referred to as allocation units. If the size attribute is specified, then the allocated size is the largest multiple of allocation units that is less than or equal to the specified size. For example, if 300M is specified for the size attribute, then 288 MB (16x18) is allocated, because 288 is the largest multiple of 16 that is less than or equal to 300.

    A minimum of 1 allocation unit is always allocated, so the minimum size for a grid disk is 16 MB. Any size value less than 16 MB is rounded up to 16 MB.

    Before specifying the size attribute, ensure that you first determine the available free space on each target cell disk by using the LIST CELLDISK command. For example, LIST CELLDISK cdisk ATTRIBUTES freespace.

  • The offset attribute determines the position on the hard disk where the grid disk is allocated. The outermost tracks have lowest offset values. If the offset attribute is not specified, then the lowest available offset is automatically chosen in order of grid disk creation.

    Note:

    The offset attribute does not apply to flash storage.

  • The size and offset attributes are specified as a number of bytes, unless the suffix M (megabytes), G (gigabytes), or T (terabytes) is included with the number, such as size=300M, or size=150G.

  • The CREATE GRIDDISK ALL ... command skips disks which do not have enough free space for a minimum sized grid disk (16 MB). In this case, the skipped grid disks are identified in the command output and the command continues.

  • The value of the availableTo attribute is set to the names of the clients registered for DB-scoped security. The value for each client name is the database unique name (DB_UNIQUE_NAME). The specified clients are those that are allowed to access the grid disk. If a value is entered for availableTo, then only the specified clients have access to the grid disk; otherwise, any client can access the grid disk.

  • Do not edit the value of idp.type or idp.boundary. Oracle Exadata System Software passes a hint to Oracle ASM about the type of interleaved grid disk, either normal redundancy or high redundancy. Oracle ASM sets the default value for idp.type to static and idp.boundary to the type of redundancy used in the underlying grid disks. The default value of the idp.type attribute is static for Oracle Exadata Storage Server disk groups created on interleaved grid disks.

    Note:

    Interleaved grid disks are deprecated in Oracle Exadata System Software release 19.1.0.

  • The cachingPolicy attribute can be set to default or none. The default option allows the data in the grid disk to be cached in the flash cache.

    Flash cache is not used with data files placed in an Oracle ASM disk group composed of grid disks with cachingPolicy=none.

    Oracle Exadata Deployment Assistant (OEDA) configures the grid disks supporting the RECO disk group to use cachingPolicy=none. Consequently, flash cache is not used for any data files placed in the RECO disk group.

  • The virtualSize attribute is used to create an Oracle ASM SPARSE disk group. The maximum virtual size for a sparse grid disk is approximately 100 TB. Sparse grid disks are available for Oracle Exadata Database Machine X3-2 and later.

    Note:

    The Oracle Database and Oracle Grid Infrastructure software must be release 12.1.0.2.0 BP5 or later when using sparse grid disks.

Example 7-85 Creating Grid Disks

This examples shows how to create grid disks.

CellCLI> CREATE GRIDDISK ALL HARDDISK PREFIX='data01,data02', size='500G,300G'

CellCLI> CREATE GRIDDISK ALL HARDDISK PREFIX=data03

CellCLI> CREATE GRIDDISK data1_CD_01_cell01 CELLDISK=CD_01_cell01, size=200G

CellCLI> CREATE GRIDDISK data2_CD_02_cell01 CELLDISK=CD_02_cell01, size=200G

CellCLI> CREATE GRIDDISK data3_CD_03_cell01 CELLDISK=CD_03_cell01

CellCLI> CREATE GRIDDISK ALL PREFIX=data10, availableTo='+asm,db1,db2'

CellCLI> CREATE GRIDDISK hr7_CD_07_cell01 CELLDISK=CD_07_cell01, availableTo='asm_hr,hrdb0'

CellCLI> CREATE GRIDDISK GD123 CELLDISK=RECO_CD123, size=100G, cachingPolicy=none

Example 7-86 Creating a SPARSE Grid Disk

CellCLI> CREATE GRIDDISK spar01 celldisk=CD_01_cel01, size=10G, virtualsize=100G

Parent topic: CREATE

7.7.4.7 CREATE KEY

Purpose

The CREATE KEY command creates and displays a random hexadecimal string to assign client keys. The use of CREATE KEY ensures that the security key is in the correct format. This command provides a way to generate a key in the correct format, and it can be run on any cell.

Syntax

CREATE KEY

Usage Notes

The security key must be entered in the cellkey.ora configuration file on the computer hosts that contain clients for which you want to authorize access to a cell.

The key is also assigned to clients that access grid disk storage.

The key must be copied manually to the hosts and cells.

Example 7-87 Creating a Key

This example shows the CREATE command with the KEY object. 

CellCLI> CREATE KEY
         3452c64fec9a5800bbe48d4093269400

Related Topics

Parent topic: CREATE

7.7.4.8 CREATE PMEMCACHE

Purpose

The CREATE PMEMCACHE command creates a persistent memory (PMEM) cache for I/O requests.

Note:

The CREATE PMEMCACHE command can only be used on Exadata X8M and X9M storage server models.

Syntax

CREATE PMEMCACHE { ALL [ size = cache_size ] | 
          CELLDISK='cdisk1[,cdisk2]...' [ , size=cache_size ] }

Usage Notes

  • The ALL argument creates the PMEM cache on all PMEM cell disks. If the ALL argument is not specified, then specific PMEM cell disks must be specified by using the CELLDISK argument. The PMEM cache is spread as evenly as possible across the PMEM cell disks.

  • PMEM cache space is allocated in 16 MB chunks, referred to as allocation units, with a minimum of 1 allocation unit. Consequently, when the size argument is specified, the actual space allocated to the PMEM cache is at least 16 MB or the largest multiple of 16 MB that is less than or equal to the specified size. For example, if size=500M is specified, then 496 MB is allocated using 31 allocation units.

  • Before specifying the size attribute, use the following command to check the available free space on the PMEM cell disks: 

    LIST CELLDISK ATTRIBUTES freespace WHERE disktype=PMEM

  • If the size attribute is not specified, then the PMEM cache consumes all of the available space (allocation units).

  • Cell disks used by the PMEM cache cannot be exported.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, you can interchangeably use CREATE XRMEMCACHE instead of CREATE PMEMCACHE.

Examples

Example 7-88 Creating PMEM Cache

The following command demonstrates how to create a 64 GB PMEM cache on specific PMEM cell disks.

CREATE PMEMCACHE celldisk='PM_01_mycell,PM_02_mycell', size = 64G

The following command demonstrates how to create a 64 GB PMEM cache using all PMEM cell disks.

CREATE PMEMCACHE ALL size = 64G

Parent topic: CREATE

7.7.4.9 CREATE PMEMLOG

Purpose

The CREATE PMEMLOG command creates the persistent memory (PMEM) log on a cell for redo log write requests.

Note:

The CREATE PMEMLOG command can only be used on Exadata X8M and X9M storage server models.

Syntax

CREATE PMEMLOG { ALL [ size=log_size ] | 
          CELLDISK='cdisk1[,cdisk2]...' [ , size=log_size ] }

Usage Notes

  • The ALL argument creates the PMEM log on all PMEM cell disks. If the ALL argument is not specified, then specific PMEM cell disks must be specified by using the CELLDISK argument. The PMEM log is spread as evenly as possible across the PMEM cell disks.

  • PMEM log space is allocated in 16 MB chunks, referred to as allocation units, with a minimum of 1 allocation unit. Consequently, when the size argument is specified, the actual space allocated to the PMEM log is at least 16 MB or the largest multiple of 16 MB that is less than or equal to the specified size. For example, if size=300M is specified, then 288 MB is allocated using 18 allocation units.

  • If a size is not specified, then a default size is used. Commencing with Oracle Exadata System Software version 20.1.0, the default size is 10176 MB (9.9375 GB). Previously, the default size was 960 MB.

  • To change the size of the PMEM log, use the DROP PMEMLOG command to drop the PMEM log, and then use the CREATE PMEMLOG command to create a PMEM log with the new size.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, you can interchangeably use CREATE XRMEMLOG instead of CREATE PMEMLOG.

Note:

By default, the CREATE PMEMCACHE command uses all available space on each PMEM cell disk. Therefore, it is recommended to create the PMEM log before the PMEM Cache to ensure that both objects are accommodated.

Examples

The following example shows how to create the PMEM log on a cell.

Example 7-89 Creating the PMEM Log

To create the PMEM log using the default size spread across all available PMEM cell disks, use the following command:

CellCLI> CREATE PMEMLOG ALL

To create the PMEM log with a size of 1 GB spread across all available PMEM cell disks, use the following command:

CellCLI> CREATE PMEMLOG ALL SIZE=1g

To create the PMEM log using the default size spread across specific PMEM cell disks, use the following command:

CellCLI> CREATE PMEMLOG CELLDISK='PM_01_mycell,PM_02_mycell,PM_03_mycell,PM_04_mycell'

To create the PMEM log with a size of 1 GB spread across specific PMEM cell disks, use the following command:

CellCLI> CREATE PMEMLOG CELLDISK='PM_01_mycell,PM_02_mycell,PM_03_mycell,PM_04_mycell', size=1G

Parent topic: CREATE

7.7.4.10 CREATE QUARANTINE

Purpose

The CREATE QUARANTINE command allows a quarantine to be created manually.

Syntax

CREATE QUARANTINE quarantineType=value quarantinePlan="SYSTEM", 
                  dbUniqueName=value[, attributename=value]...

Usage Notes

Manual creation of quarantines should be done in coordination with Oracle Support Services. In general, manual quarantines are created to proactively isolate SQL statements that are known to cause problems.

  • quarantineType specifies the type of quarantine to be created, such as SQLID and SQL_PLAN.

  • quarantinePlan must be set to SYSTEM. Oracle Support Services may specify other values.

  • dbUniqueName specifies the name of the database that has the quarantine.

Example 7-90 Creating a Quarantine

This example shows the CREATE command with the QUARANTINE object. 

CELLCLI> CREATE QUARANTINE  DBUG comment='For debugging quarantines"

CellCLI> CREATE QUARANTINE quarantineType="SQLID", quarantinePlan="SYSTEM", -
         dbUniqueName="DB1", sqlid="5xnjp4cutc1s7";

Related Topics

Parent topic: CREATE

7.7.4.11 CREATE ROLE

Purpose

The CREATE ROLE command creates a role for a user accessing a cell.

Syntax

CREATE ROLE  role_name1 [, role_name2, ...]

Usage Notes

The role name should be unique.

Example 7-91 Creating a Role

This example shows how to create a role named gd_monitor. 

CellCLI>CREATE ROLE gd_monitor

Parent topic: CREATE

7.7.4.12 CREATE THRESHOLD

Purpose

The CREATE THRESHOLD command creates a threshold object that specifies the conditions for generation of a metric alert.

Syntax

CREATE THRESHOLD name attributename=value [, attributename=value]...

Usage Notes

The attributes that can be specified are comparison, critical, occurrences, observation, and warning.

  • The name argument is required. The name is comprised of a metric name and an object name with the format metricName.objectName, such as db_io_rq_sm_sec.db123 or ct_io_wt_rq.interactive. Use the LIST METRICCURRENT metric command to display the available object name for metric. The object name is optional.

  • When a object name is not specified, then the threshold is applied to all metric objects for the given metric.

  • The comparison attribute is required with a condition value. The value must be '<', '<=', '=', '>=', or '>'.

  • The occurrences attribute specifies the number of consecutive measurements over the threshold value that trigger a state change.

  • The observation attribute is the number of measurements over which measured values are averaged.

  • A state change to the value set in warning or critical causes a stateful alert to be generated.

  • The GD_SP_PRCT_ALLOCATED metric has a built-in threshold, and automatically sends alerts. Create thresholds for other metrics to receive alerts for those metrics.

When specifying occurrences and observations, you need the specified number of consecutive occurrences of sample averages over the number of observations to cause an alert. For example, if the following five observations (observations=5) happen on a cell, then the average sample would be 10 because the number of consecutive occurrences (occurrences=2) had values of 5 and 15. 

Observation 1: 0
Observation 2: 30
Observation 3: 0
Observation 4: 5
Observation 5: 15

Example 7-92 Creating a Threshold

This example shows how to create a threshold.

CellCLI> CREATE THRESHOLD db_io_rq_sm_sec.db123 comparison='>', critical=120

CellCLI> CREATE THRESHOLD ct_io_wt_sm.interactive warning=10, critical=20, -
         comparison='=', occurrences=2, observation=5

Related Topics

Parent topic: CREATE

7.7.4.13 CREATE USER

Purpose

The CREATE USER command creates a user.

Syntax

CREATE USER name PASSWORD = *

Usage Notes

  • The user name should be unique.

  • celladmin, cellmonitor, and root are reserved user names that cannot be used with the CREATE USER command.

  • The system prompts for a password for the new user. The password must have 12 to 40 alphanumeric characters or special characters !@#$%^&*() with at least one digit, one lowercase letter, and one uppercase letter. Starting with Oracle Exadata System Software release 18.1.0.0.0, the password can be 8 to 40 characters in length and can also utilize the special characters - and _.

  • The new password cannot be the same as the current password for the user.

Example 7-93 Creating a User

This example shows how to create a user.

CellCLI> CREATE USER agarcia PASSWORD = *
password: 
Confirm password: password
User agarcia successfully created.

Parent topic: CREATE

7.7.4.14 CREATE XRMEMCACHE

Purpose

Starting with Exadata X10M, the CREATE XRMEMCACHE command creates the Exadata RDMA Memory Cache (XRMEM cache).

Note:

On Exadata X8M and X9M systems, the CREATE XRMEMCACHE command is equivalent to the CREATE PMEMCACHE command.

Syntax

CREATE XRMEMCACHE

Usage Notes

Starting with Exadata X10M, the XRMEM cache is created automatically during cell creation on supported storage servers. The XRMEM cache is also re-created automatically during Cell Server (CELLSRV) startup if it does not exist.

Parent topic: CREATE

7.7.4.15 CREATE XRMEMLOG

Purpose

Starting with Oracle Exadata System Software release 23.1.0, the CREATE XRMEMLOG command is equivalent to the CREATE PMEMLOG command.

Note:

The CREATE XRMEMLOG command can only be used on Exadata X8M and X9M storage server models.

Parent topic: CREATE

7.7.5 DESCRIBE

Purpose

The DESCRIBE command displays a list of attributes for the object type that is provided as an argument. The list of attributes indicates whether each attribute can be modified.

Syntax

DESCRIBE object_type

Usage Notes

  • The object_type is one of the object types supported by CellCLI.

  • The list of attributes can be used as arguments in the LIST command.

  • DESCRIBE does not display all of the attributes for the objects.

Parent topic: CellCLI Command Reference

7.7.5.1 DESCRIBE ACTIVEREQUEST

Purpose

The DESCRIBE ACTIVEREQUEST command displays a list of attributes for the ACTIVEREQUEST object type.

Syntax

DESCRIBE ACTIVEREQUEST

Usage Notes

The attributes for the DESCRIBE ACTIVEREQUEST command can include the following:

  • asmDiskGroupNumber: Number of the Oracle ASM disk group

  • asmFileIncarnation: Incarnation number of the Oracle ASM file

  • asmFileNumber: Number of the Oracle ASM file

  • consumerGroupID: Identifier of the consumer group

  • consumerGroupName: Name of the consumer group

  • dbID: Database unique name

  • dbName: Database name

  • dbRequestID: Identifier of the database request

  • fileType: File type associated with the request

  • id: Unique identifier of the active request

  • instanceNumber: Instance number associated with the request

  • ioBytes: Number of bytes of I/O against the grid disk in the current session

  • ioBytesSoFar: Number of total bytes of I/O

  • ioGridDisk: Grid disk used by a request

  • ioOffset: Measure of the offset on the grid disk

  • ioReason: Reason for I/O activity, such as a control-file read

  • ioType: Type of active request, such as file initialization, read, write, predicate pushing, filtered backup read, or predicate push read

  • name: Unique name of the active request

  • objectNumber: Object number associated with the request

  • parentID: Identifier of the parent request

  • pdbID: Identifier of the pluggable database

  • requestState: State of the active request, such as

    • Accessing Disk

    • Computing Result

    • Network Receive

    • Network Send

    • Queued Extent

    • Queued for Disk

    • Queued for File Initialization

    • Queued for Filtered Backup Read

    • Queued for Network Send

    • Queued for Predicate Pushing

    • Queued for Read

    • Queued for Write

    • Queued in Resource Manager

  • sessionID: Identifier of the session

  • sessionSerNumber: Serial number of the database session

  • sqlID: Identifier of the SQL command associated with the request

  • tableSpaceNumber: Tablespace number associated with the request

Example 7-94 Describing the ACTIVEREQUEST Object

This example shows the DESCRIBE command with the ACTIVEREQUEST object. 

CellCLI> DESCRIBE ACTIVEREQUEST

         name
         asmDiskGroupNumber
         asmFileIncarnation
         asmFileNumber
         consumerGroupID
         consumerGroupName
         dbID
         dbName
         dbRequestID
         fileType
         id
         instanceNumber
         ioBytes
         ioBytesSofar
         ioGridDisk
         ioOffset
         ioReason
         ioType
         objectNumber
         parentID
         pdbID
         requestState
         sessionID
         sessionSerNumber
         sqlID
         tableSpaceNumber

Parent topic: DESCRIBE

7.7.5.2 DESCRIBE ALERTDEFINITION

Purpose

The DESCRIBE ALERTDEFINITION command displays a list of attributes for the ALERTDEFINITION object type.

Syntax

DESCRIBE ALERTDEFINITION

Usage Notes

The attributes for the DESCRIBE ALERTDEFINITION command can include the following:

  • alertShortName: Abbreviated name for the alert. If the alert is based on a metric, then the short name is the same as the corresponding metric name attribute.

  • alertSource: Source of the alert, such as BMC or ADR

  • alertType: Type of the alert. Values are stateful or stateless.

    • Stateful alerts are automatically cleared on transition to normal.

    • Stateless alerts are never cleared. You can change the alert by setting the examinedBy attribute.

  • description: Description for the alert

  • metricName: Metric name if the alert is based on a metric

  • name: Identifier for the alert

Example 7-95 Describing the ALERTDEFINITION Object

CellCLI> DESCRIBE ALERTDEFINITION

         name
         alertShortName
         alertSource
         alertType
         description
         metricName

Related Topics

Parent topic: DESCRIBE

7.7.5.3 DESCRIBE ALERTHISTORY

Purpose

The DESCRIBE ALERTHISTORY command displays a list of attributes for the ALERTHISTORY object type.

Syntax

DESCRIBE ALERTHISTORY

Usage Notes

The attributes for the DESCRIBE ALERTHISTORY command can include the following:

  • alertAction: Recommended action to perform for this alert
  • alertDescription: Description for the alert
  • alertMessage: Brief explanation of the alert
  • alertSequenceID: Unique sequence ID for the alert. When an alert changes its state, such as warning to critical or critical to clear, another occurrence of the alert is created with the same sequence number and a time stamp of the transition.
  • alertShortName: Abbreviated name for the alert. If the alert is based on a metric, then the short name is the same as the corresponding metric name attribute.

  • alertType: Type of the alert. Values are stateful or stateless.

    • Stateful alerts are automatically cleared on transition to normal.
    • Stateless alerts are never cleared. You can change the alert by setting the examinedBy attribute.
  • beginTime: Time stamp when an alert changes its state
  • endTime: Time stamp for the end of the period when an alert changes its state
  • examinedBy: Administrator who reviewed the alert
  • failedMail: Intended e-mail recipient when a notification failed
  • failedSNMP: Intended SNMP subscriber when a notification failed
  • metricObjectName: Object, such as cell disk or grid disk, for which a metric threshold has caused an alert
  • metricValue: Value of the metric that caused the alert
  • name: Unique identifier for the alert

  • notificationState: Number indicating progress in notifying subscribers to alert messages:

    • 0, or "non-deliverable": Never tried
    • 1, or "sent": Sent successfully
    • 2, or "attempting delivery": Retrying, up to 5 times
    • 3, or "delivery failed": Retry failed 5 times
    • 4, or "creating diagpack": The diagnostic packaging and the outgoing alert email are still pending for this alert. It is used by MS to keep track of the alerts that have not been processed or are being processed. This enables MS, in the event of a restart, to continue processing alerts with state 4 and send the alert email.
  • sequenceBeginTime: Time stamp when an alert sequence ID is first created
  • serviceRequestLink: The URL to the service request associated with the alert
  • serviceRequestNumber: The service request number associated with the alert

  • severity: Severity level. Values are:

    • clear
    • info
    • warning
    • critical

Example 7-96 Describing the ALERTHISTORY Object

CellCLI> DESCRIBE ALERTHISTORY

         name
         alertAction
         alertDescription
         alertMessage
         alertSequenceID
         alertShortName
         alertType
         beginTime
         endTime
         examinedBy              modifiable
         failedMail
         failedSNMP
         metricObjectName
         metricValue
         notificationState
         sequenceBeginTime
         serviceRequestLink
         serviceRequestNumber
         severity

Related Topics

Parent topic: DESCRIBE

7.7.5.4 DESCRIBE CELL

Purpose

The DESCRIBE CELL command displays a list of attributes for the CELL object type.

Syntax

DESCRIBE CELL

Usage Notes

The following list contains the attributes for the DESCRIBE CELL command.

  • accessLevelPerm: Specifies the access level at which the cell runs by default. Value is either remoteLoginEnabled or remoteLoginDisabled.

  • accessLevelTemp: Duration of time in which the access level is temporarily changed from the setting of accessLevelPerm

  • accountLockInDays: Number of days after a password expires before a user account is locked. Available with Oracle Exadata System Software release 19.1.0 or later.

  • bbuStatus: Status of hard disk controller battery-backed unit (BBU)

  • cellsrvStatus: Status of Cell Server

  • cellVersion: Release number of the cell software

  • columnarCachePersMode: Controls the persistent columnar cache feature

  • comment: User-supplied text string

  • cpuCount: Number of CPUs on the cell

  • dbPerfDataSuppress: Specifies which databases should not have their statistics reported in Automatic Workload Repository (AWR) reports

  • diagHistoryDays: Number of days ADR files are retained. The default is 7 days.

  • diagPackEmailAttach: Whether a diagpack is included as an attachment in the alert email or not. The default is true.

  • diagPackUploadEnabled: Whether the auto diagpack upload feature is enabled or not. The default is true.

  • doNotServiceLEDStatus: Status of the cell DoNotService LED. The value can be on or off.

  • eighthRack: Specifies whether Oracle Exadata Database Machine Eighth Rack configuration for storage cells is enabled or disabled

  • emailFormat: File format for email messages. The value can be html or text.

  • emailSubscriber: List of names that subscribe to the alert notifications

  • events: String for events++ that is passed to Cell Server for debugging and trace information purposes

  • exacliEnabled: Specifies whether exacli is enabled or disabled. The default value is true (enabled).

  • fanCount: Count of working fans and total fans, displayed as working/total

  • fanStatus: Status of the fan. The value can be normal, warning, or critical.

  • flashCacheCompress: Setting for flash cache compression. The value can be true or false.

  • flashCacheMode: Setting for flash cache. The value can be writethrough or writeback. The default is writethrough.

  • httpsAccess: Control list of IP addresses for HTTPs port access to the Exadata RESTful Service. Available with Oracle Exadata System Software release 19.1.0 or later.

  • id: Global unique identifier (GUID) supplied by the hardware vendor

  • interconnect[1-8]: Interconnect1 to interconnect8 for the cell. For example: bondeth0 or bondib0.

  • interconnectCount: Number of active InfiniBand network interconnects

  • iormBoost: Ratio of the cumulative number of positions in the I/O queue that were skipped because of IORM scheduling to the number of I/Os that where scheduled. This ratio is calculated by sampling the changes each minute in the two numbers.

  • IOTimeoutThreshold: Specifies the timeout threshold. If cell I/O takes longer than the defined threshold, then the I/O is canceled, and Oracle ASM redirects the I/O to another mirror copy of the data.

  • ipaddress[1-8]: ipaddress1 to ipaddress8 for the cell

  • kernelVersion: Version of the host kernel software

  • location: Physical location of the cell hardware supplied by the user

  • locatorLEDStatus: Status of cell LOCATE LED. The value can be on or off.

  • mailServer: Fully qualified domain name of the email relay server used to send alert notifications

  • makeModel: Make and model of the cell hardware supplied by the vendor

  • memoryGB: The memory in gigabytes for the cell

  • metricCollection: Indicator for whether Management Server performs metric collection. Values are TRUE or FALSE. If set to FALSE, then all collection and alert mining is stopped. The default setting is TRUE.

  • metricHistoryDays: Number of days that regular metric history files are retained. The default is 7 days.

  • msStatus: Status of Management Server

  • name: Unique name for the cell

  • notificationMethod: Notification method for alerts. The value should be mail, snmp, none, or both mail and snmp.

  • notificationPolicy: Indicator for severity alerts to be sent to subscribers. The value for notificationPolicy should be none or any combination of critical, warning, and clear.

  • offloadGroupEvents: Used only under the guidance of Oracle Support

  • pmemCacheMode: PMEM cache mode.

    The default is writethrough. Commencing with Oracle Exadata System Software release 23.1.0, writethrough is the only supported mode for PMEM cache. Previously, writeback mode was available but was not generally recommended.

  • powerCount: Count of power supplies, displayed as working/total

  • powerStatus: Status of the power. The value can be normal, warning, or critical.

  • pwdExpInDays: The number of days before a user's password expires. Available with Oracle Exadata System Software release 19.1.0 or later.

  • pwdExpWarnInDays: The number of days before a user's password expires that a warning message is issued during login attempts. Available with Oracle Exadata System Software release 19.1.0 or later.

  • rackName: The name of the rack

  • releaseImageStatus: Indicator for knowing whether imaging is successful

  • releaseTrackingBug: Patch number for the cell software, such as 30441371

  • releaseVersion: Release number for the cell software, such as 19.3.1.0.0.191018

  • remotePwdChangeAllowed: Whether or not a user password can be changed remotely through REST services. Available with Oracle Exadata System Software release 19.1.0 or later.

  • rescuePlan: A list of commands that you can run after a server rescue to restore settings, such as IORM plans, thresholds, and notifications, to the last known values.

  • rollbackVersion: The inactive image version that the cell maintains. If patchmgr rollback is invoked for the cell, the value displayed by rollbackVersion is the software version that will be reinstated.

  • rpmVersion: The RPM version of the cell

  • rsStatus: Status of Restart Server

  • securityCert: The certified identity of the cell. Either CA-certified identity or the default self-certified identity.

  • siteName: The site name for the cell

  • smtpFrom: User name that appears in the From: header of the alert notifications
  • smtpFromAddr: Email address that appears in the From: header of the alert notifications. This email address is not authenticated with the email server.

  • smtpPort: Email server port used to send alert notifications

  • smtpToAddr: Address to which email is sent. It can be a comma-delimited list in quotation marks to allow multiple subscribers to alerts.

  • smtpUseSSL: Specification to use Secure Socket Layer (SSL) encryption for alert notifications.

  • snmpSubscriber: List of hosts that subscribe to the SNMP alert notifications

  • snmpUser: Defines the user who receives SNMP alerts

  • status: Status of the cell

  • storageIndexPersMode: Controls the persistent storage index feature

  • syslogConf: Designates syslog messages that should be forwarded to a specified management server. Uses the following syntax for the attribute, where selector is the message type, and node is the specified server: 

    syslogconf = (selector @node' [, 'selector @node']... )

    Both selector and node follow syslog.conf standard syntax rules.

  • syslogFormat: A string representing the format for syslog messages. Available with Oracle Exadata System Software release 19.1.0 or later.

  • temperatureReading: Current temperature (Celsius) of the cell obtained from the BMC

  • temperatureStatus: Status of the temperature. The value can be normal, warning, or critical.

  • traceLevel: The level for which trace messages are written. The default is FINE. The value can be:

    • A valid Java logging level

      • SEVERE
      • WARNING
      • INFO
      • CONFIG
      • FINE
      • FINER
      • FINEST

    • A valid Oracle Diagnostic Logging (ODL) logging level

      • INCIDENT_ERROR:1
      • ERROR:1
      • WARNING:1
      • NOTIFICATION:1
      • NOTIFICATION:16
      • TRACE:1
      • TRACE:16
      • TRACE:32

  • upTime: Time (days, hours:minutes) since the system was restarted

  • usbStatus: Status of the USB device

Examples

The following example shows the DESCRIBE command with the CELL object.

Example 7-97 Describing the CELL Object

CellCLI> DESCRIBE CELL

	name                   modifiable
	accessLevelPerm        modifiable
	accessLevelTemp        modifiable
	accountLockInDays      modifiable
	bbuStatus
	cellsrvStatus
	cellVersion
	comment                modifiable
	cpuCount
	dbPerfDataSuppress     modifiable
	diagHistoryDays        modifiable
	diagPackEmailAttach    modifiable
	diagPackUploadEnabled  modifiable
	doNotServiceLEDStatus
	eighthRack             modifiable
	emailFormat            modifiable
	emailSubscriber        modifiable
	events                 modifiable
	exacliEnabled          modifiable
	fanCount
	fanStatus
	flashCacheCompress     modifiable
	flashCacheMode         modifiable
	httpsAccess            modifiable
	id
	interconnect1          modifiable
	interconnect2          modifiable
	interconnect3          modifiable
	interconnect4          modifiable
	interconnect5          modifiable
	interconnect6          modifiable
	interconnect7          modifiable
	interconnect8          modifiable
	interconnectCount
	iormBoost
	IOTimeoutThreshold     modifiable
	ipaddress1
	ipaddress2
	ipaddress3
	ipaddress4
	ipaddress5
	ipaddress6
	ipaddress7
	ipaddress8
	kernelVersion
	location               modifiable
	locatorLEDStatus
	mailServer             modifiable
	makeModel
	memoryGB
	metricCollection       modifiable
	metricHistoryDays      modifiable
	msStatus
	notificationMethod     modifiable
	notificationPolicy     modifiable
	offloadGroupEvents     modifiable
	pmemCacheMode          modifiable
	powerCount
	powerStatus
	pwdExpInDays           modifiable
	pwdExpWarnInDays       modifiable
	rackName               modifiable
	releaseImageStatus
	releaseTrackingBug
	releaseVersion
	remotePwdChangeAllowed modifiable
	rescuePlan             hidden
	rollbackVersion
	rpmVersion
	rsStatus
	securityCert           modifiable
	siteName               modifiable
	smtpFrom               modifiable
	smtpFromAddr           modifiable
	smtpPort               modifiable
	smtpToAddr             modifiable
	smtpUseSSL             modifiable
	snmpSubscriber         modifiable
	snmpUser               modifiable
	status
	syslogConf             modifiable
	syslogFormat           modifiable
	temperatureReading
	temperatureStatus
	traceLevel             modifiable
	upTime
	usbStatus

Related Topics

Parent topic: DESCRIBE

7.7.5.5 DESCRIBE CELLDISK

Purpose

The DESCRIBE CELLDISK command displays a list of attributes for the CELLDISK object type.

Syntax

DESCRIBE CELLDISK

Usage Notes

The attributes displayed by the DESCRIBE CELLDISK command can include:

  • comment: User comment for the cell disk.

  • creationTime: Time stamp when the cell disk was created.

  • deviceName: Operating system device name of the LUN used by the cell disk.

  • devicePartition: Operating system device name of the partition that is used by the cell disk.

  • diskType: The type of disk.

  • errorCount: Number of errors that occurred on the cell disk.

  • flushError: Errors reported by while flushing the flash cache.

  • flushStatus: The current status of the flash cache flush operation.

  • freeSpace: Amount of unused space available on the cell disk.

  • id: Global unique identifier (GUID) that is generated when the cell disk is created.

  • name: Unique name of the cell disk.

  • physicalDisk: Name of the physical disk on which the cell disk is located.

  • size: Total size of the cell disk.

  • status: Current status of the cell disk, such as normal or importRequired.

Example 7-98 Describing the CELLDISK Object

This shows the DESCRIBE command with the CELLDISK object. 

CellCLI> DESCRIBE CELLDISK

         name                    modifiable
         comment                 modifiable
         creationTime
         deviceName
         devicePartition
         diskType
         errorCount
         flushError              hidden
         flushStatus             hidden
         freeSpace
         id
         physicalDisk
         size
         status

Related Topics

Parent topic: DESCRIBE

7.7.5.6 DESCRIBE DATABASE

Purpose

Displays the specified attributes for active databases.

Syntax

DESCRIBE DATABASE

Usage Notes

The attributes for the DESCRIBE DATABASE command include the following:

  • name: The database name.

  • asmClusterName: The name of the associated ASM cluster. This attribute is populated when ASM-scoped security is configured.

  • databaseID: The unique identifier for the database.

  • flashCacheLimit: Specifies the amount of flash cache space that is available to the database. The value is a soft limit, so the database may consume more space if the flash cache is not full.

  • flashCacheMin: Specifies the minimum amount of flash cache space that is guaranteed for the database.

  • flashCacheSize: Specifies the maximum amount of flash cache space that is available to the database. The value is a hard limit that cannot be exceeded at any time.

  • iormDiskLimit: Specifies the I/O utilization limit for the database, expressed as a percentage of the available disk resources.

  • iormDiskShare: Specifies the relative share of disk I/O resources that is available to the database. A higher share value implies higher priority and more access to the I/O resources.

  • iormFlashLimit: Specifies the I/O utilization limit for the database, expressed as a percentage of the available flash resources.

  • iormFlashShare: Specifies the relative share of flash I/O resources that is available to the database. A higher share value implies higher priority and more access to the I/O resources.

  • lastRequestTime: The time stamp of the last request from the database.

  • pmemCacheLimit: Specifies the amount of PMEM cache space that is available to the database. The value is a soft limit, so the database may consume more space if the PMEM cache is not full.

  • pmemCacheMin: Specifies the minimum amount of PMEM cache space that is guaranteed for the database.

  • pmemCacheSize: Specifies the maximum amount of PMEM cache space that is available to the database. The value is a hard limit that cannot be exceeded at any time.

  • profile: The IORM profile associated with the database.

  • xrmemCacheLimit: Specifies the amount of XRMEM cache space that is available to the database. The value is a soft limit, so the database may consume more space if the XRMEM cache is not full.

  • xrmemCacheMin: Specifies the minimum amount of XRMEM cache space that is guaranteed for the database.

  • xrmemCacheSize: Specifies the maximum amount of XRMEM cache space that is available to the database. The value is a hard limit that cannot be exceeded at any time.

Examples

The following example shows the DESCRIBE command with the DATABASE object.

Example 7-99 Describing the DATABASE Object

CellCLI> DESCRIBE DATABASE
        name
        asmClusterName
        databaseID
        flashCacheLimit
        flashCacheMin
        flashCacheSize
        iormDiskLimit
        iormDiskShare
        iormFlashLimit
        iormFlashShare
        lastRequestTime
        pmemCacheLimit
        pmemCacheMin
        pmemCacheSize
        profile
        xrmemCacheLimit
        xrmemCacheMin
        xrmemCacheSize

Related Topics

Parent topic: DESCRIBE

7.7.5.7 DESCRIBE DISKMAP

Purpose

Displays the grid disk attributes for a physical disk.

Syntax

DESCRIBE DISKMAP

Usage Notes

The attributes displayed by the DESCRIBE DISKMAP command can include:

  • celldisk: The cell disk name

  • devicePartition: The disk partition name

  • gridDisks: The name of the grid disks associated with the disk

  • name: The disk name.

  • physicalSerial: The serial number of the disk

  • physicalSize: The size of the disk

  • slotNumber: The slot number of the disk

  • status: The disk status

Examples

The following example shows the DESCRIBE command with the DISKMAP object.

Example 7-100 Describing the DISKMAP Object

CellCLI> DESCRIBE CELLDISK

         name
         celldisk
         devicePartition
         gridDisks
         physicalSerial
         physicalSize
         slotNumber
         status

Parent topic: DESCRIBE

7.7.5.8 DESCRIBE FLASHCACHE

Purpose

The DESCRIBE FLASHCACHE command displays a list of attributes for the FLASHCACHE object type.

Syntax

DESCRIBE FLASHCACHE

Usage Notes

The attributes displayed by the DESCRIBE FLASHCACHE command can include:

  • cellDisk: Cell disk names that contain Exadata Smart Flash Cache.

  • creationTime: Time stamp when the Exadata Smart Flash Cache was created.

  • degradedCelldisks: List of cell disks configured for cache but not currently available..

  • effectiveCacheSize: Usable cache size after deducting space on unavailable cell disks.

  • id: Global unique identifier (GUID) that is generated when the Exadata Smart Flash Cache is created.

  • name: Unique name of the Exadata Smart Flash Cache.

  • size: Total size of the Exadata Smart Flash Cache.

  • status: Current status of the Exadata Smart Flash Cache, such as normal, warning or critical.

Examples

The following example shows the DESCRIBE command with the FLASHCACHE object.

Example 7-101 Describing the FLASHCACHE Object

CellCLI> DESCRIBE FLASHCACHE

         name
         cellDisk               modifiable
         creationTime
         degradedCelldisks
         effectiveCacheSize 
         id
         size                   modifiable
         status

Parent topic: DESCRIBE

7.7.5.9 DESCRIBE FLASHCACHECONTENT

Purpose

The DESCRIBE FLASHCACHECONTENT command displays a list of attributes for the FLASHCACHECONTENT object type.

Syntax

DESCRIBE FLASHCACHECONTENT

Usage Notes

The attributes displayed by the DESCRIBE FLASHCACHECONTENT command can include:

  • cachedKeepSize: Size, in bytes, cached in keep mode for this object.

  • cachedSize: Size, in bytes, cached for this object.

  • cachedWriteSize: Size, in bytes, of cached data for this object in write-back flash cache that has not yet been written to hard disk.

  • columnarCacheSize: Size, in bytes, cached in Hybrid Columnar Compression (HCC) format for this object.

  • columnarKeepSize: Size, in bytes, cached in Hybrid Columnar Compression (HCC) format that is in keep mode for this object.

  • dbID: Database unique name identifier.

  • dbUniqueName: Database unique name.

  • hitCount: Number of I/Os which read data from flash cache for this object.

  • hoursToExpiration: Time before this object is downgraded from keep section, if not accessed again.

  • missCount: Number of I/Os which read data from disk for this object.

  • objectNumber: Mostly specifies the Oracle Database dictionary object number of the database object (table, index, partition, and so on) that is associated with the FLASHCACHECONTENT object.

    Additionally, the following values have special meaning:

    • 0 (zero) indicates that the object number is undefined. This value is often used in conjunction with internal I/O performed by ASM.

    • 4294967292 indicates that the FLASHCACHECONTENT object contains ASM Dynamic Volume Manager (ADVM) data.

    • 4294967293 indicates cached redo log data.

    • 4294967294 and 4294967295 indicate data from internal database objects, such as temporary segments, rollback segments, control file data, and so on, which is not associated with a specific data object (table, index, partition, and so on).

  • tableSpaceNumber: Tablespace number associated with the database object.

Examples

The following example shows the DESCRIBE command with the FLASHCACHECONTENT object.

Example 7-102 Describing the FLASHCACHECONTENT Object

CellCLI> DESCRIBE FLASHCACHECONTENT

         cachedKeepSize
         cachedSize
         cachedWriteSize
         columnarCacheSize
         columnarKeepSize
         dbID
         dbUniqueName
         hitcount
         hoursToExpiration
         missCount
         objectNumber
         tableSpaceNumber

Parent topic: DESCRIBE

7.7.5.10 DESCRIBE FLASHLOG

Purpose

The DESCRIBE FLASHLOG command displays a list of attributes for the FLASHLOG object type.

Syntax

DESCRIBE FLASHLOG

Usage Notes

The attributes displayed by the DESCRIBE FLASHLOG command can include:

  • cellDisk: Names of the cell disks that contain Oracle Exadata Smart Flash Log.

  • creationTime: Timestamp when Oracle Exadata Smart Flash Log was created.

  • degradedCelldisks: List of cell disks configured for Oracle Exadata Smart Flash Log, but not currently available.

  • effectiveSize: Size of available Oracle Exadata Smart Flash Log after deducting space on unavailable cell disks.

  • efficiency: Efficiency of Oracle Exadata Smart Flash Log expressed as a percentage.

  • id: Global unique identifier (GUID) generated when Oracle Exadata Smart Flash Log is created.

  • name: Unique name of Oracle Exadata Smart Flash Log.

  • size: Total size of Oracle Exadata Smart Flash Log.

  • status: Current status of Oracle Exadata Smart Flash Log, such as normal, warning or critical. Status normal indicates all flash disks are available. Status warning indicates some flash disks are not available. Status critical indicates all flash disks are unavailable.

Examples

The following example shows the DESCRIBE command with the FLASHLOG object.

Example 7-103 Describing the FLASHLOG Object

CellCLI> DESCRIBE FLASHLOG

         name
         cellDisk
         creationTime
         degradedCelldisks
         effectiveSize
         efficiency
         id
         size
         status

Parent topic: DESCRIBE

7.7.5.11 DESCRIBE GRIDDISK

Purpose

The DESCRIBE GRIDDISK command displays a list of attributes for the GRIDDISK object type.

Syntax

DESCRIBE GRIDDISK

Usage Notes

The attributes for the DESCRIBE GRIDDISK command include the following:

  • asmDeactivationOutcome: Indicator whether a grid disk can be deactivated without loss of data. A value of YES indicates the grid disk can be deactivated without data loss.

  • asmDiskgroupName: Name of the Oracle ASM disk group.

  • asmDiskName: Name of the Oracle ASM disk.

  • asmDiskRepairTime: The amount of time the grid disk can remain offline before it is dropped by Oracle ASM.

  • asmDiskSize: Size of the Oracle ASM disk.

    This attribute is available in Oracle Exadata System Software release 12.1.2.3.0 and later.

  • asmFailGroupName: Name of the Oracle ASM failure group.

  • asmModeStatus: Indicator shows the current Oracle ASM usage of a grid disk. Statuses are ONLINE, OFFLINE, DROPPED, UNUSED, SYNCING, or UNKNOWN.

  • availableTo: Names of the clients that can access this grid disk.

  • cachedBy: The name of the flash disks that are currently caching data for this grid disk for write-back flash cache.

  • cachingPolicy: The flash caching policy for this grid disk. Values are default or none.

    • default means data for this grid disk uses the flash cache.

    • none means data for this grid disk do not use flash cache.

    The caching policy can be set when creating a grid disk, or using the ALTER GRIDDISK command.

  • cellDisk: Name of the cell disk that contains the grid disk.

  • comment: User-supplied text string.

  • creationTime: Time stamp when the grid disk was created.

  • diskType: The type of disk.

  • errorCount: Count of hardware errors detected by the cell disk containing this grid disk.

  • id: Global unique identifier (GUID) that is generated when the grid disk is created.

  • name: Unique name of the grid disk.

  • size: Total size of the grid disk.

  • sizeAllocated: Total size of materialized space used by data in a sparse grid disk.

    This attribute is available in Oracle Exadata System Software 22.1.0 and later. It applies to sparse grid disks only.

  • sparse: Whether the grid disk is a sparse disk.

  • status: Current status of the grid disk, such as active, inactive, not present or importRequired.

  • virtualSize: The size of the disk group for the sparse grid disks.

Note:

The asmDeactivationOutcome and asmModeStatus attributes must be explicitly specified when using the LIST GRIDDISK command.

Example 7-104 Describing the GRIDDISK Object

This example shows the DESCRIBE command with the GRIDDISK object. 

CellCLI> DESCRIBE GRIDDISK

         name                      modifiable
         asmDeactivationOutcome    hidden
         asmDiskgroupName   
         asmDiskName
         asmDiskRepairTime         hidden
         asmDiskSize               hidden
         asmFailGroupName
         asmModeStatus             hidden
         availableTo               modifiable
         cachedBy
         cachingPolicy             modifiable
         cellDisk
         comment                   modifiable
         creationTime
         diskType
         errorCount
         id
         size                      modifiable
         sizeAllocated
         sparse
         status
         virtualSize               modifiable

Related Topics

Parent topic: DESCRIBE

7.7.5.12 DESCRIBE IBPORT

Purpose

The DESCRIBE IBPORT command displays a list of attributes for the IBPORT object type on systems that use InfiniBand Network Fabric.

Note:

This command does not apply to Oracle Exadata X8M systems.

Syntax

DESCRIBE IBPORT

Usage Notes

The attributes for the DESCRIBE IBPORT command can include the following:

  • activeSlave: Indicator whether the port is currently the active port for the bonded IP.

  • dataRate: The data rate of the InfiniBand Network Fabric port.

  • hcaFWVersion: The version of the host channel adapter firmware.

  • id: The Global unique identifier (GUID) of the InfiniBand Network Fabric port.

  • lid: The local identifier of the InfiniBand Network Fabric port. It is unique within the subnet, and the 16-bit identifiers are used within a network by switches for routing.

  • linkDowned: The number of times the port training state machine has failed the link error recovery process, and halted the link.

  • linkIntegrityErrs: The number of link integrity errors.

  • linkRecovers: The number of times the port training state machine has successfully completed the link error recovery process.

  • name: The name of the InfiniBand Network Fabric port.

  • physLinkState: The physical link state.

  • portNumber: The port number of the InfiniBand Network Fabric port.

  • rcvConstraintErrs: The number of received constraint errors experienced by the InfiniBand Network Fabric port.

  • rcvData: The number of 32-bit data words received by the InfiniBand Network Fabric port.

  • rcvErrs: The number of packets received at the InfiniBand Network Fabric port containing an error.

  • rcvRemotePhysErrs: The number of physical errors experienced at the InfiniBand Network Fabric port.

  • status: The link status.

  • symbolErrs: The number of minor link errors experienced at the InfiniBand Network Fabric port.

  • vl15Dropped: The number of incoming VL15 packets dropped at the InfiniBand Network Fabric port due to resource limitations, such as lack of buffers.

  • xmtConstraintErrs: The number of transmitted constraint errors experienced at the InfiniBand Network Fabric port.

  • xmtData: The number of 32-bit data words transmitted on the InfiniBand Network Fabric port.

  • xmtDiscards: The number of outbound packets discarded by the InfiniBand Network Fabric port because the port was down or congested.

Example 7-105 Describing the IBPORT Object

The following example shows the DESCRIBE command with the IBPORT object on systems that use InfiniBand Network Fabric. 

CellCLI> DESCRIBE IBPORT

        name
        activeSlave
        dataRate
        hcaFWVersion
        id
        lid
        linkDowned
        linkIntegrityErrs
        linkRecovers
        physLinkState
        portNumber
        rcvConstraintErrs
        rcvData
        rcvErrs
        rcvRemotePhysErrs
        status
        symbolErrs
        vl15Dropped
        xmtConstraintErrs
        xmtData
        xmtDiscards

Parent topic: DESCRIBE

7.7.5.13 DESCRIBE IORMPLAN

Purpose

The DESCRIBE IORMPLAN command displays a list of attributes for the IORMPLAN object type.

Syntax

DESCRIBE IORMPLAN

Usage Notes

The attributes for the DESCRIBE IORMPLAN command can include the following:

  • catPlan: Allocation plan for the categories set up in the databases using the cell.

  • dbPlan: Allocation plan for the databases using the cell.

  • name: Unique name of the interdatabase plan. The name value is automatically set to cellname_IORMPLAN.

  • objective: Optimization mode for IORM.

  • status: Current status of the interdatabase plan, either active or inactive.

Examples

The following example shows the DESCRIBE command with the IORMPLAN object.

Example 7-106 Describing the IORMPLAN Object

CellCLI> DESCRIBE IORMPLAN

         name
         catPlan                 modifiable
         dbPlan                  modifiable
         objective               modifiable
         status

Related Topics

Parent topic: DESCRIBE

7.7.5.14 DESCRIBE KEY

Purpose

The DESCRIBE KEY command displays a list of attributes for the KEY object type.

Syntax

DESCRIBE KEY

Usage Notes

The attributes for the DESCRIBE KEY command can include the following:

  • key: Random hexadecimal string used to assign client keys.

  • name: Name of the key. The value of this field is not displayed with LIST.

  • type: The type of key.

Examples

The following example shows the DESCRIBE command with the KEY object.

Example 7-107 Describing the KEY Object

CellCLI> DESCRIBE KEY

         name
         key                     modifiable
         type                    modifiable

Related Topics

Parent topic: DESCRIBE

7.7.5.15 DESCRIBE LUN

Purpose

The DESCRIBE LUN command displays a list of attributes for the LUN object type.

Syntax

DESCRIBE LUN

Usage Notes

The attributes for the DESCRIBE LUN command can include the following:

  • cellDisk: The name of the flash disk, for example FD_02_rack1celadm10. Not used for hard disks.

  • deviceName: Operating system device name for the LUN. For example, /dev/c1d5

  • diskType: The type of disk.

  • errorCount: Number of errors on this LUN.

  • id: Identifier assigned by the system.

  • isSystemLun: Indicator whether the disk is a system disk. If value is TRUE, then the disk is a system disk. If the value is FALSE, then the disk is not a system disk, and only has data on it.

  • lunSize: Raw size of the LUN before being converted to a cell disk.

  • lunUID: Unique identifier assigned by the system.

  • lunWriteCacheMode: Status of LUN write cache. The status can be in Write Through Mode or Write Back Mode.

  • name: Unique name assigned to the LUN. This might be different (or extended from) the LUN ID if the ID is not unique.

  • overProvisioning: Indicator of the percentage of over-provisioned blocks in flash storage that are still available for a particular LUN. This attribute is only used for flash disks.

  • physicalDrives: Physical disk names that form the LUN.

  • raidLevel: Value of the RAID level that is used on the LUN. For example: RAID 0.

  • status: Status of the LUN, which can be normal, warning, or critical.

Examples

The following example shows the DESCRIBE command with the LUN object.

Example 7-108 Describing the LUN Object

CellCLI> DESCRIBE LUN

         name
         cellDisk
         deviceName
         diskType
         errorCount
         id
         isSystemLun
         lunSize
         lunUID
         lunWriteCacheMode
         overProvisioning
         physicalDrives
         raidLevel
         status

Related Topics

Parent topic: DESCRIBE

7.7.5.16 DESCRIBE METRICCURRENT

Purpose

The DESCRIBE METRICCURRENT command displays a list of attributes for the METRICCURRENT object type.

Syntax

DESCRIBE METRICCURRENT

Usage Notes

The attributes for the DESCRIBE METRICCURRENT command can include the following:

  • alertState: Indicator of the alert state. Values are normal, warning, or critical.

  • collectionTime: Time stamp when the metric value was collected

  • metricObjectName: Name of the object, such as cell disk, grid disk, and consumer group, being measured

  • metricType: Specification for how the statistic was created or defined

  • metricValue: Value of the metric when it was collected

  • name: Unique name of the current metric

  • objectType: Type of object being measured. Values are:

    • CELL

    • CELL_FILESYSTEM

    • CELLDISK

    • FLASHCACHE

    • FLASHLOG

    • GRIDDISK

    • IBPORT

    • IORM_CATEGORY

    • IORM_CONSUMER_GROUP

    • IORM_DATABASE

    • IORM_PLUGGABLE_DATABASE

    • HOST_INTERCONNECT

    • SMARTIO

Examples

The following example shows the DESCRIBE command with the METRICCURRENT object.

Example 7-109 Describing the METRICCURRENT Object

CellCLI> DESCRIBE METRICCURRENT

         name
         alertState
         collectionTime
         metricObjectName
         metricType
         metricValue
         objectType

Related Topics

Parent topic: DESCRIBE

7.7.5.17 DESCRIBE METRICDEFINITION

Purpose

The DESCRIBE METRICDEFINITION command displays a list of attributes for the METRICDEFINITION object type.

Syntax

DESCRIBE METRICDEFINITION

Usage Notes

The attributes for the DESCRIBE METRICDEFINITION command can include the following:

  • description: Description of the metric.

  • metricType: Indicator of how the statistic was created or defined. The options are as follows:

    • cumulative: Cumulative statistics since the metric was created.

    • instantaneous: Value at the time that the metric is collected.

    • rate: Rates computed by averaging statistics over observation periods.

    • transition: Transition metrics are collected at the time their value has changed and typically capture important transitions in hardware status.

  • name: Unique name of the metric definition. (Details follow this list.)

  • objectType: Type of object being measured. Values are:

    • CELL

    • CELL_FILESYSTEM

    • CELLDISK

    • FLASHCACHE

    • FLASHLOG

    • GRIDDISK

    • IBPORT

    • IORM_CATEGORY

    • IORM_CONSUMER_GROUP

    • IORM_DATABASE

    • IORM_PLUGGABLE_DATABASE

    • HOST_INTERCONNECT

    • SMARTIO

  • persistencePolicy: Amount of time metric values are stored.

  • unit: Unit for the metric explicitly, and is related to the metric collected:

    • Number

    • % (percentage)

    • F (Fahrenheit)

    • C (Celsius)

    • IO/sec

    • “IO requests”

    • KB

    • KB/sec

    • MB

    • MB/sec

    • /min

    • ms

    • ms/request

    • ms/sec

    • us (microseconds)

    • us/request

    • us/sec

The value of the name attribute is a composite of abbreviations. The attribute value starts with an abbreviation of the object type on which the metric is defined:

  • CD_ (cell disk)

  • CG_ (IORM consumer group, database-qualified)

  • CL_ (cell)

  • CT_ (IORM category)

  • DB_ (IORM database-level)

  • FC_ (flash cache)

  • FL_ (flash log)

  • GD_ (grid disk)

  • IORM

  • N_ (network, IBPORT, HOST_INTERCONNECT)

  • PDB_ (IORM pluggable database)

  • SIO_ (Smart IO)

After the abbreviation of the object type, most of the name attributes contain one of the following combinations to identify the operation:

  • IO_BY (I/O amount)

  • IO_RQ (number of I/O requests)

  • IO_TM (I/O latency)

  • IO_WT (I/O wait time)

  • FC_IO_BY (Flash cache I/O amount)

  • FC_IO_RQ (Flash cache I/O requests)

  • FD_IO_BY (Flash disk I/O amount)

  • FD_IO_RQ (Flash disk I/O requests)

  • FD_IO_TM (Flash disk latency)

  • FD_IO_UTIL (Flash disk utilization percentage)

Next, in the name could be _R or _W for read or write. Following that in the name attribute value there might be _SM or _LG to identify small or large blocks, respectively. At the end of the name, there could be _SEC to signify per seconds or _RQ to signify per request.

For consumer group and category metrics, read or write details are omitted.

For example:

  • CD_IO_RQ_R_SM is the number of requests to read small blocks on a cell disk.

  • GD_IO_TM_W_LG is the microseconds of I/O latency writing large blocks on a grid disk.

Examples

The following example shows the DESCRIBE command with the METRICDEFINITION object.

Example 7-110 Describing the METRICDEFINITION Object

CellCLI> DESCRIBE METRICDEFINITION

         name
         description
         metricType
         objectType
         persistencePolicy
         unit

Related Topics

Parent topic: DESCRIBE

7.7.5.18 DESCRIBE METRICHISTORY

Purpose

The DESCRIBE METRICHISTORY command displays a list of attributes for the METRICHISTORY object type.

Syntax

DESCRIBE METRICHISTORY

Usage Notes

The attributes for the DESCRIBE METRICHISTORY command can include the following:

  • alertState: Indicator of the alert state. Values are normal, warning, or critical.

  • collectionTime: Time stamp when the metric value was collected

  • metricObjectName: Name of the object, such as cell disk, grid disk, and consumer group, being measured

  • metricType: Specification for how the statistic was created or defined

  • metricValue: Value of the metric when it was collected

  • metricValueAvg: Average value of the metric

  • metricValueMax: Maximum value of the metric

  • metricValueMin: Minimum value of the metric

  • name: Name of the current metric

  • objectType: Type of object being measured. Values are:

    • CELL

    • CELL_FILESYSTEM

    • CELLDISK

    • FLASHCACHE

    • FLASHLOG

    • GRIDDISK

    • IBPORT

    • IORM_CATEGORY

    • IORM_CONSUMER_GROUP

    • IORM_DATABASE

    • IORM_PLUGGABLE_DATABASE

    • HOST_INTERCONNECT

    • SMARTIO

Examples

The following example shows the DESCRIBE command with the METRICHISTORY object.

Example 7-111 Describing the METRICHISTORY Object

CellCLI> DESCRIBE METRICHISTORY

         name
         alertState
         collectionTime
         metricObjectName
         metricType
         metricValue
         metricValueAvg
         metricValueMax
         metricValueMin
         objectType

Parent topic: DESCRIBE

7.7.5.19 DESCRIBE OFFLOADGROUP

Purpose

The DESCRIBE OFFLOADGROUP command displays a list of attributes for the OFFLOADGROUP object type.

Syntax

DESCRIBE OFFLOADGROUP

Usage Notes

The attributes for the DESCRIBE OFFLOADGROUP command can include the following:

  • autoStart: Whether the offload server associated with the offload group is dynamically started. Value can be either true or false.

  • comment: An optional comment

  • creationTime: The time when the offload group was created

  • id: An identifier for the offload group

  • isSystemGroup: Whether the offload group was created by the system software. The value can be either true or false.

  • name: The name of the offload group

  • package:

  • runtimeState: The current state of the offload group process. The value can be running or stopped.

Example 7-112 Describing the OFFLOADGROUP Object

The following example shows ....

CellCLI> DESCRIBE OFFLOADGROUP
        name
        autoStart
        comment                modifiable
        creationTime
        id
        isSystemGroup
        package                modifiable
        runtimeState

Parent topic: DESCRIBE

7.7.5.20 DESCRIBE PHYSICALDISK

Purpose

The DESCRIBE PHYSICALDISK command displays a list of attributes for the PHYSICALDISK object type.

Syntax

DESCRIBE PHYSICALDISK

Usage Notes

The attributes for the DESCRIBE PHYSICALDISK command can include the following:

  • ctrlFirmware: The hard disk controller software version

  • ctrlHwVersion: The hard disk controller hardware version

  • deviceID: The ID for the physical disk

  • deviceName: The name of the physical disk device, for example /dev/sdx

  • diskType: Type of the disk, whether it is a HardDisk, FlashDisk, or M2Disk.

  • enclosureDeviceId: Identifier for the hard disk enclosure. This attribute is only applicable to Oracle Exadata System Software on Oracle Exadata Storage Server.

  • errCmdTimeoutCount: The count of execution of commands related to physical disks that timed out, for example, disk firmware upgrade, listing physical disks, and so on.

  • errHardReadCount: Total count of read errors on a physical disk

  • errHardWriteCount: Total count of write errors on a physical disk

  • errorCount: The sum of all known error counts for a physical disk

  • errOtherCount: Total error count of all other (unknown) errors for a physical disk

  • errSeekCount: Total number of disk seek errors

  • flashLifeLeft: The percentage of flash disk life left for a disk

  • hotPlugCount: Total number of times a disk has been pulled out and reinserted (hot plugged)

  • lastFailureReason: The reason for the last physical disk failure

  • luns: List of LUNs converted from this disk. M.2 disks do not have LUNs.

  • makeModel: Model description provided by the system

  • name: Unique name of the physical disk

  • notPresentSince: Date at which the disk was no longer detected

  • physicalFirmware: The version of the firmware

  • physicalInsertTime: Time that the disk was inserted

  • physicalInterface: Interface type used by the hard disk. For example, SAS

  • physicalPort: (Only appplicable for HP models) The physical disk port value

  • physicalRPM: The RPM value of a physical hard disk. This attribute is also used to determine the disk type (SATA or SAS).

  • physicalSerial: System-assigned unique ID

  • physicalSize: Size of the disk in bytes

  • physicalUseType: Intended use of the disk, for example, Data Drive

  • sectorRemapCount: Total number of physical disk sectors that have been remapped because of sector failures

  • slotNumber: Physical location of disk. This attribute is only applicable to Oracle Exadata System Software on Oracle Exadata Storage Server.

  • status: Status of the physical disk. Values can be:

    • failed: The disk has failed. In earlier releases, this status was called critical.

    • normal: The disk is functioning normally

    • not present: The disk has been removed

    • peer failure: Flash disk failure only

    • poor performance: The disk is performing poorly

    • predictive failure: The disk is expected to fail

    • write-through caching: Flash disk caching only.

Example 7-113 Describing the PHYSICALDISK Object in Oracle Exadata Storage Server

CellCLI> DESCRIBE PHYSICALDISK
        name
        ctrlFirmware
        ctrlHwVersion
        deviceId
        deviceName
        diskType
        enclosureDeviceId
        errCmdTimeoutCount
        errHardReadCount
        errHardWriteCount
        errorCount
        errOtherCount
        errSeekCount
        flashLifeLeft
        hotPlugCount
        lastFailureReason
        luns
        makeModel
        notPresentSince
        physicalFirmware
        physicalInsertTime
        physicalInterface
        physicalPort
        physicalRPM
        physicalSerial
        physicalSize
        physicalUseType
        sectorRemapCount
        slotNumber
        status

Parent topic: DESCRIBE

7.7.5.21 DESCRIBE PLUGGABLEDATABASE

Purpose

The DESCRIBE PLUGGABLEDATABASE command displays a list of attributes for the PLUGGABLEDATABASE object type.

Syntax

DESCRIBE PLUGGABLEDATABASE

Usage Notes

The attributes for the DESCRIBE PLUGGABLEDATABASE command can include the following:

  • asmClusterName: The Oracle ASM cluster name or alias. Available with Oracle Exadata System Software release 19.1.0 or later.

  • flashCacheLimit: The specified limit on the Flash cache for this pluggable database (PDB)

  • flashCacheMin: The specified minimum size of the Flash cache for this PDB

  • flashCacheSize: The size of the Flash cache specified for this PDB

  • iormLimit: The disk I/O utilization limit for the PDB. Available with Oracle Exadata System Software release 19.1.0 or later.

  • iormShare: The IORM share number for the PDB. Available with Oracle Exadata System Software release 19.1.0 or later.

  • name: The name of the PDB

  • pdbID: The ID for the PDB

  • pmemCacheLimit: The specified limit on the PMEM cache for this pluggable database (PDB)

  • pmemCacheMin: The specified minimum size of the PMEM cache for this PDB

  • pmemCacheSize: The size of the PMEM cache specified for this PDB

  • name: The pluggable database (PDB) name.

  • asmClusterName: The name of the associated ASM cluster. This attribute is populated when ASM-scoped security is configured.

  • containerName: The name of the container database (CDB)

  • flashCacheLimit: Specifies the amount of flash cache space that is available to the PDB. The value is a soft limit, so the PDB may consume more space if the flash cache is not full.

  • flashCacheMin: Specifies the minimum amount of flash cache space that is guaranteed for the PDB.

  • flashCacheSize: Specifies the maximum amount of flash cache space that is available to the PDB. The value is a hard limit that cannot be exceeded at any time.

  • iormDiskLimit: Specifies the I/O utilization limit for the PDB, expressed as a percentage of the available disk resources.

  • iormFlashLimit: Specifies the I/O utilization limit for the PDB, expressed as a percentage of the available flash resources.

  • iormShare: Specifies the relative share of I/O resources that is available to the PDB. A higher share value implies higher priority and more access to the I/O resources.

  • pdbID: The unique identifier for the PDB.

  • pmemCacheLimit: Specifies the amount of PMEM cache space that is available to the PDB. The value is a soft limit, so the PDB may consume more space if the PMEM cache is not full.

  • pmemCacheMin: Specifies the minimum amount of PMEM cache space that is guaranteed for the PDB.

  • pmemCacheSize: Specifies the maximum amount of PMEM cache space that is available to the PDB. The value is a hard limit that cannot be exceeded at any time.

  • xrmemCacheLimit: Specifies the amount of XRMEM cache space that is available to the PDB. The value is a soft limit, so the PDB may consume more space if the XRMEM cache is not full.

  • xrmemCacheMin: Specifies the minimum amount of XRMEM cache space that is guaranteed for the PDB.

  • xrmemCacheSize: Specifies the maximum amount of XRMEM cache space that is available to the PDB. The value is a hard limit that cannot be exceeded at any time.

Example 7-114 Describing the PLUGGABLEDATABASE Object

CellCLI> DESCRIBE PLUGGABLEDATABASE
        name
        asmClusterName
        containerName
        flashCacheLimit
        flashCacheMin
        flashCacheSize
        iormDiskLimit
        iormFlashLimit
        iormShare
        pdbID
        pmemCacheLimit
        pmemCacheMin
        pmemCacheSize
        xrmemCacheLimit
        xrmemCacheMin
        xrmemCacheSize

Parent topic: DESCRIBE

7.7.5.22 DESCRIBE PMEMCACHE

Purpose

The DESCRIBE PMEMCACHE command displays a list of attributes for the PMEMCACHE object type.

Note:

The DESCRIBE PMEMCACHE command can only be used on Exadata X8M and X9M storage server models.

Syntax

DESCRIBE PMEMCACHE

Usage Notes

The attributes displayed by the DESCRIBE PMEMCACHE command can include:

  • cellDisk: Cell disk names used by the PMEM cache.

  • creationTime: Time stamp when the PMEM cache was created.

  • degradedCelldisks: List of cell disks configured for the cache but not currently available.

  • effectiveCacheSize: Usable PMEM cache size after deducting space on unavailable cell disks.

  • id: Global unique identifier (GUID) that is generated when the PMEM cache is created.

  • name: Unique name of the PMEM cache.

  • size: Total size of the PMEM cache.

  • status: Current status of the PMEM cache, such as normal, warning or critical.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, you can interchangeably use DESCRIBE XRMEMCACHE instead of DESCRIBE PMEMCACHE.

Examples

The following example shows the DESCRIBE command with the PMEMCACHE object.

Example 7-115 Describing the PMEMCACHE Object

CellCLI> DESCRIBE PMEMCACHE

         name
         cellDisk               modifiable
         creationTime
         degradedCelldisks
         effectiveCacheSize 
         id
         size                   modifiable
         status

Parent topic: DESCRIBE

7.7.5.23 DESCRIBE PMEMLOG

Purpose

The DESCRIBE PMEMLOG command displays a list of attributes for the PMEMLOG object type.

Note:

The DESCRIBE PMEMLOG command can only be used on Exadata X8M and X9M storage server models.

Syntax

DESCRIBE PMEMLOG

Usage Notes

The attributes displayed by the DESCRIBE PMEMLOG command can include:

  • cellDisk: Names of the cell disks that contain PMEMLOG.

  • creationTime: Timestamp when PMEMLOG was created.

  • degradedCelldisks: List of cell disks configured for PMEMLOG that are not currently available.

  • effectiveSize: Size of available PMEMLOG after deducting space on unavailable cell disks.

  • efficiency: Efficiency of PMEMLOG expressed as a percentage.

  • id: Global unique identifier (GUID) generated when PMEMLOG is created.

  • name: Unique name of PMEMLOG.

  • size: Total size of the PMEMLOG.

  • status: Current status of PMEMLOG.

    • normal: All PMEM cell disks are available.
    • warning: Some PMEM cell disks are not available.
    • critical: All PMEM cell disks are unavailable.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, you can interchangeably use DESCRIBE XRMEMLOG instead of DESCRIBE PMEMLOG.

Example 7-116 Describing the PMEMLOG Object

This example shows the DESCRIBE command with the PMEMLOG object. 

CellCLI> DESCRIBE PMEMLOG
     name
     cellDisk
     creationTime
     degradedCelldisks
     effectiveSize
     efficiency
     id
     size
     status

Parent topic: DESCRIBE

7.7.5.24 DESCRIBE QUARANTINE

Purpose

The DESCRIBE QUARANTINE command displays a list of attributes for the QUARANTINE object type.

Syntax

DESCRIBE QUARANTINE

Usage Notes

The attributes for the DESCRIBE QUARANTINE command can include the following:

  • asmClusterId: Identifier of the ASM cluster. This attribute is available in Exadata software 12.2.1.1.0 and later.

  • catDBPlan: The name of the category plan

  • cellsrvChecksum: Checksum of the CELLSRV binary

  • clientPID: The process identifier for the client process which crashed the cell

  • comment: Comment for the quarantine

  • conDbUniqueID: The container database unique ID for the quarantine

  • conDbUniqueName: The container database unique name for the quarantine

  • crashReason: Reason for the crash

  • creationTime: Quarantine creation time

  • dbUniqueID: The database unique ID for the quarantine

  • dbUniqueName: The database unique name for the quarantine

  • fineGrainControl:

  • fineGrainValue:

  • incidentID: The incident identifier of the crash that caused the quarantine creation

  • interDBPlan: The name of the interdatabase resource plan

  • intraDBPlan: The name of the intradatabase resource plan

  • ioBytes: The bytes of quarantined disk region. This is applicable to disk region quarantine only.

  • ioGridDisk: The grid disk name for quarantined disk region. This is applicable to disk region quarantine only.

  • ioOffset: The I/O offset for quarantined disk region. This is applicable to disk region quarantine only.

  • name: Identifier of the quarantine

  • objectID:

  • planLineID: The SQL Plan Line identifier. This is applicable to SQL Plan quarantine only.

  • quarantineMode:

  • quarantinePlan: This is usually SYSTEM

  • quarantineReason: The reason for creation of the quarantine

  • quarantineType: The type of quarantine created

  • remoteHostName: The host name of the remote host that ran the client process that crashed the cell

  • rpmVersion: The RPM version of the cell being used when the cell crashed

  • sqlID: The SQLID of the SQL statement that crashed a cell

  • sqlPlanHashValue: The SQL Plan hash value. This is applicable to SQL Plan quarantine only.

Example 7-117 Describing the QUARANTINE Object

CellCLI> DESCRIBE QUARANTINE
        name
        asmClusterId
        catDBPlan
        cellsrvChecksum
        clientPID
        comment                modifiable
        conDbUniqueID
        conDbUniqueName
        crashReason
        creationTime
        dbUniqueID
        dbUniqueName
        fineGrainControl
        fineGrainValue
        incidentID
        interDBPlan
        intraDBPlan
        ioBytes
        ioGridDisk
        ioOffset
        objectID
        planLineID
        quarantineMode
        quarantinePlan
        quarantineReason
        quarantineType
        remoteHostName
        rpmVersion
        sqlID
        sqlPlanHashValue

Parent topic: DESCRIBE

7.7.5.25 DESCRIBE ROLE

Purpose

The DESCRIBE ROLE command displays a list of attributes for the ROLE object type.

Syntax

DESCRIBE ROLE

Usage Notes

The attributes for the DESCRIBE ROLE command can include the following:

  • name: Unique name of the user assigned the role

  • privileges: Privileges granted to the role

Example 7-118 Describing the ROLE Object

CellCLI> DESCRIBE ROLE
        name
        privileges

Parent topic: DESCRIBE

7.7.5.26 DESCRIBE SOFTWAREHISTORY

Purpose

The DESCRIBE SOFTWAREHISTORY command displays a list of attributes for the ALERTHISTORY object type.

Syntax

DESCRIBE SOFTWAREHISTORY

Usage Notes

The attributes for the DESCRIBE SOFTWAREHISTORY command can include the following:

  • name: The name of the software update

  • status: The status of the software update

Example 7-119 Describing the SOFTWAREHISTORY Object

CellCLI> DESCRIBE SOFTWAREHISTORY
        name
        status

Parent topic: DESCRIBE

7.7.5.27 DESCRIBE SOFTWAREUPDATE

Purpose

The DESCRIBE SOFTWAREUPDATE command displays a list of attributes for the SOFTWAREUPDATE object type.

Syntax

DESCRIBE SOFTWAREUPDATE

Usage Notes

The attributes for the DESCRIBE SOFTWAREUPDATE command can include the following:

  • frequency: The time period in which this software update is performed automatically. The value can be none, daily, weekly, or biweekly. The value none is available in Oracle Exadata System Software release 19.1.0 or later.
  • name: The name of the patch to use in the update, or unknown. If the name defaults to unknown, then when the software update is performed, the most recent patch is chosen for the upgrade.
  • status: The status of this software update.
  • store: The URL for the location of the software update file
  • time: The specified date and time at which the software update should be performed
  • timeLimitInMinutes: The number of minutes a cell will spend waiting to update the software before canceling and issuing an alert.

Example 7-120 Describing the SOFTWAREUPDATE Object

CellCLI> DESCRIBE SOFTWAREUPDATE
        name                   modifiable
        status
        store                  modifiable
        time                   modifiable
        timeLimitInMinutes     modifiable

Parent topic: DESCRIBE

7.7.5.28 DESCRIBE THRESHOLD

Purpose

The DESCRIBE THRESHOLD command displays a list of attributes for the THRESHOLD object type.

Syntax

DESCRIBE THRESHOLD

Usage Notes

The attributes displayed by the DESCRIBE THRESHOLD command can include:

  • comparison: Operator for comparing the metric value to the threshold value (>, >=, =, <, <=) to determine whether the value violates the threshold.

  • critical: Limit beyond which the metric value is considered to be in the critical state for generating alerts

  • name: Unique name of the threshold

  • observation: Number of measurements over which the rate metric is averaged before being compared with the threshold value

  • occurrences: Number of consecutive violations of the threshold limit by the metric value before the appropriate alert is issued

  • warning: Limit beyond which the metric value is considered to be in the warning state for generating alerts

Example 7-121 Describing the THRESHOLD Object

CellCLI> DESCRIBE THRESHOLD

         name
         comparison              modifiable
         critical                modifiable
         observation             modifiable
         occurrences             modifiable
         warning                 modifiable

Parent topic: DESCRIBE

7.7.5.29 DESCRIBE USER

Purpose

The DESCRIBE USER command displays a list of attributes for the USER object type.

Syntax

DESCRIBE USER

Usage Notes

The attributes displayed by the DESCRIBE USER command can include:

  • name: Unique name of the user

  • roles: Roles assigned to the user

Example 7-122 Describing the USER Object

CellCLI> DESCRIBE USER
         name
         roles

Parent topic: DESCRIBE

7.7.5.30 DESCRIBE XRMEMCACHE

Purpose

Starting with Exadata X10M, the DESCRIBE XRMEMCACHE command displays a list of attributes for the Exadata RDMA Memory Cache.

Note:

On Exadata X8M and X9M systems, the DESCRIBE XRMEMCACHE command is equivalent to the DESCRIBE PMEMCACHE command.

Syntax

DESCRIBE XRMEMCACHE

Usage Notes

Starting with Exadata X10M, the attributes displayed by the DESCRIBE XRMEMCACHE command include:

  • name: Unique name of the Exadata RDMA Memory Cache (XRMEM cache).

  • creationTime: Time stamp when the XRMEM cache was created.

  • effectiveCacheSize: Usable XRMEM cache size.

Examples

The following example shows the DESCRIBE command with the XRMEMCACHE object.

Example 7-123 Describing the XRMEMCACHE Object

CellCLI> DESCRIBE XRMEMCACHE

         name
         creationTime
         effectiveCacheSize

Parent topic: DESCRIBE

7.7.5.31 DESCRIBE XRMEMLOG

Purpose

Starting with Oracle Exadata System Software release 23.1.0, the DESCRIBE XRMEMLOG command is equivalent to the DESCRIBE PMEMLOG command.

Note:

The DESCRIBE XRMEMLOG command can only be used on Exadata X8M and X9M storage server models.

Parent topic: DESCRIBE

7.7.6 DROP

Purpose

The DROP command removes the named objects from the cell or resets a cell.

Syntax

DROP object_type [object_name [, object_name]...] [options]

Usage Notes

  • When multiple objects are the target of a DROP command, there is the possibility of partial success. If an error occurs, then the command is interrupted, and the remaining objects are not dropped.

Parent topic: CellCLI Command Reference

7.7.6.1 DROP ALERTHISTORY

Purpose

The DROP ALERTHISTORY command removes alerts from the alert history of a cell.

Syntax

DROP ALERTHISTORY {ALL | alert1 {, alert2}, ...}

Usage Notes

  • In the command, alertN is the name of the alert to be dropped from the history.

  • When dropping stateful alerts, you must drop all members of the alert sequence at the same time. If you do not drop all members, then an error is issued by the system.

Examples

The following example shows the DROP ALERTHISTORY command.

Example 7-124 Dropping a Cell Alert History

CellCLI> DROP ALERTHISTORY 1, 2_1, 2_2

Parent topic: DROP

7.7.6.2 DROP CELL

Purpose

The DROP CELL command resets a cell to its original state.

Syntax

DROP CELL [ERASE = value] [FORCE]

Usage Notes

  • This command is run from within the cell.

  • All cell disks, grid disks, and thresholds are dropped. The interdatabase plan is reset to its default state. All cell attributes are set to default values.

  • The FORCE option is required if the grid disks are configured on any cell disks when DROP CELL is issued. Otherwise, an error is reported.

  • Flash cache compression must be disabled before securely erasing a drive.

  • The ERASE option erases the content on the disk by overwriting the content. The values are as follows:

    • 1pass: One pass, and the content is overwritten with zeros. This value is not available for flash drives.

    • 3pass: Three passes, and the content is overwritten with set data patterns. This option follows the recommendations of NNSA. This value is not available for flash drives.

    • 7pass: Seven passes, and the disk is overwritten with set data patterns. This option follows the recommendations from DOD.

  • When dropping all cells using the 1pass or 3pass option, it necessary to drop the flash disks first using the 7pass option, and then drop the cells. The following is an example of the commands: 

    CellCLI> DROP CELLDISK ALL FLASHDISK ERASE=7pass 
CellCLI> DROP CELL ERASE=1pass

  • As of Oracle Exadata System Software release 19.1.0, if you specify to erase hard disks or flash disks using 1pass, 3pass, or 7pass method on Oracle Exadata Database Machine X5 or later, Oracle Exadata System Software automatically invokes Secure Eraser to erase the disks. Secure Eraser determines whether or not the disks can be erased using the better and faster cryptographic erasure method. If some of the disks are eligible, then the cryptographic erasure method is used to erase those disks, and the originally requested method (1/3/7 pass) is used on the other disks. This feature is not used on system disks.

    See Table 7-3 for a list of the erasure methods available for each type of device.

The following table shows approximate time needed to securely erase a drive using the supported algorithms. When multiple grid disks or cell disks are dropped with the ERASE option, the command runs in parallel on all disks and flash drives. However, the recommended method of erasing data from a cell is to use Secure Erase. See Securely Erasing Database Servers and Storage Servers in Oracle Exadata Database Machine Security Guide.

Table 7-2 Estimated Erasure Times for Devices by Erasure Method

Type of Device 1pass 3pass 7pass Cryptographic

600 GB hard drive

1 hour

3 hours

7 hours

not available

1.2 TB hard drive

1.67 hours

5 hours

11.67 hours

not available

2 TB hard drive

5 hours

15 hours

35 hours

not available

3 TB hard drive

7 hours

21 hours

49 hours

not available

4 TB hard drive

8 hours

24 hours

56 hours

not available

8 TB hard drive

13.17 hours

39.5 hours

92.17 hours

1 min

10 TB hard drive

14 hours

42 hours

98 hours

1 min

14 TB hard drive

18 hours

54 hours

126 hours

1 min

22.875 GB flash drive

not available

not available

21 minutes

not available

93 GB flash drive

not available

not available

32 minutes

not available

186 GB flash drive

not available

not available

36 minutes

not available

1.6 TB flash drive

not available

not available

5.5 hours

1 min

3.2 TB flash drive

not available

not available

8 hours

1 min

Persistent Memory (PMEM) device

not available

not available

not available

1 min

4 GB Internal USB

not available

30 minutes

not available

not available
8 GB Internal USB

not available

1 hour

not available

not available

150 GB M.2 device

not available

not available

not available

1 minute

ILOM

not available

not available

not available

1 minute

Example 7-125 Dropping a Cell 

CellCLI> DROP CELL FORCE

Related Topics

Parent topic: DROP

7.7.6.3 DROP CELLDISK

Purpose

The DROP CELLDISK command removes all or the named cell disks from the cell.

This command is necessary if a cell disk fails, or it is replaced by a newer model.

Before dropping the cell disk, you should drop its grid disks and the corresponding Oracle ASM disks from the disk groups. The Oracle ASM disks should be dropped before dropping the grid disks.

Syntax

DROP CELLDISK { ALL [FLASHDISK | HARDDISK] | cdisk_name [, cdisk_name]... }
              [ERASE = value [NOWAIT]] [FORCE]

Usage Notes

  • If individual cell disks are specified, then the named cell disks (cdisk_name) are dropped.
  • If the LUN associated with the CELLDISK is flagged as automatically created, then that LUN is deleted along with the cell disk.
  • If the ALL option is specified, then all the cell disks on the cell are removed.
  • The FLASHDISK option limits the DROP CELLDISK command to cell disks that are flash disks.
  • The HARDDISK option limits the DROP CELLDISK command to cell disks that are hard disks.
  • If grid disks are configured on the cell disk when DROP CELLDISK is issued, then the FORCE option must be used or an error is reported. The FORCE option causes any grid disks to be dropped first, and then the cell disk is dropped.
  • If the specified cell disk includes flash cache, and that flash cache is in writeback mode, then the cell disk cannot be dropped.

  • As of Oracle Exadata System Software release 19.1.0, if you specify to erase hard disks or flash disks using 1pass, 3pass, or 7pass method on Oracle Exadata Database Machine X5 or later, Oracle Exadata System Software automatically invokes Secure Eraser to erase the disks. Secure Eraser determines whether or not the disks can be erased using the better and faster cryptographic erasure method. If some of the disks are eligible, then the cryptographic erasure method is used to erase those disks, and the originally requested method (1/3/7 pass) is used on the other disks. This feature is not used on system disks.

  • The ERASE option erases the content on the disk by overwriting the content. The values are as follows:
    • 1pass: One pass, and the content is overwritten with zeros. This option is not applicable for flash drives.
    • 3pass: Three passes, and the content is overwritten with set data patterns. This option follows the recommendations from the National Nuclear Security Administration (NNSA). This option is not applicable for flash drives. This value is not available for flash drives.
    • 7pass: Seven passes, and the disk is overwritten with set data patterns. This option follows the recommendations from the United States Department of Defense (DOD).

    See Table 7-2 for the approximate erasure times for each disk and erasure method.

  • Use the NOWAIT option with the ERASE option to run the command asynchronously.

  • When dropping all cell disks using the 1pass or 3pass option, you must drop the flash disks first using the 7pass option, and then drop the cell disks, for example: 

    CellCLI> DROP CELLDISK ALL FLASHDISK ERASE=7pass 
CellCLI> DROP CELLDISK ALL ERASE=1pass

The following table gives a summary of the secure erasure methods used for each device type. Hard drives, flash devices, and internal USBs are securely erased in parallel: the time required to erase one device is the same as that required for erasing multiple devices of the same kind.

Table 7-3 Methods Used to Securely Erase Various Devices

Component Make or Model Erasure Method

Hard drive

  • 8 TB hard drives on Oracle Exadata X5

  • All hard drives on Oracle Exadata X6 or later

Cryptographic erase

Hard drive

All other hard drives

1/3/7-Pass erase

Flash device

Flash devices on Oracle Exadata X5 or later

Cryptographic erase

Flash device

All other flash devices

7-pass erase

M.2 device

Oracle Exadata Database Machine X7-2 or later

Cryptographic erase

Persistent Memory (PMEM) device

 Oracle Exadata X8M or later

Cryptographic erase

Example 7-126 Examples of Dropping a Cell Disk

CellCLI> DROP CELLDISK CD_03_cell01

CellCLI> DROP CELLDISK CD_02_cell06 FORCE

CellCLI> DROP CELLDISK ALL

CellCLI> DROP CELLDISK CD_02_cell09 ERASE=1pass NOWAIT
CellDisk CD_02_cell09 erase is in progress
7.7.6.4 DROP FLASHCACHE

Purpose

The DROP FLASHCACHE command removes Exadata Smart Flash Cache from a cell.

Syntax

DROP FLASHCACHE

Usage Notes

Before dropping flash cache, the data not synchronized with the grid disk (dirty data) must be flushed from flash cache to the grid disks. Not flushing dirty data may cause data loss.

Examples

The following example shows how to remove Exadata Smart Flash Cache from a cell.

Example 7-127 Removing Exadata Smart Flash Cache

CellCLI> DROP FLASHCACHE

Related Topics

Parent topic: DROP

7.7.6.5 DROP FLASHLOG

Purpose

The DROP FLASHLOG command removes Oracle Exadata Smart Flash Log from a cell.

Syntax

DROP FLASHLOG [FORCE]

Usage Notes

The DROP FLASHLOG command can be run at runtime, but the command does not complete until all redo data on the flash disk is written to hard disk.

If FORCE is not specified, then the DROP FLASHLOG command fails if there is any saved redo. If FORCE is specified, then all saved redo is purged, and Oracle Exadata Smart Flash Log is removed.

Caution:

If DROP FLASHLOG fails due to the existence of saved redo, then do not use the FORCE option unless you are sure that all saved redo is no longer needed for any databases to perform recovery. Contact Oracle Support Services for additional information.

Examples

The following example shows how to remove Exadata Smart Flash Cache from a cell.

Example 7-128 Removing Oracle Exadata Smart Flash Log from a Cell

CellCLI> DROP FLASHLOG

CellCLI> DROP FLASHLOG FORCE

Parent topic: DROP

7.7.6.6 DROP GRIDDISK

Purpose

The DROP GRIDDISK command removes the named grid disks or removes all the grid disks specified by the ALL option.

Caution:

Before dropping a grid disk, ensure that it is not part of any Oracle ASM disk group.

Syntax

DROP GRIDDISK 
   { ALL [ FLASHDISK | HARDDISK ] PREFIX={[']gdisk_name_prefix[']|'gdisk_name_prefix1[,gdisk_name_prefix2]...'} 
   | gdisk_name1[,gdisk_name2]... }
   [ERASE=value [NOWAIT]] [FORCE]

Usage Notes

  • If one or more grid disk names (gdisk_name1, gdisk_name1, and so on) are specified, then each name identifies the individual grid disk to be removed.

  • If the ALL option is specified without FLASHDISK or HARDDISK, then the command drops all grid disks matching the PREFIX specification.

    If the ALL option is specified with FLASHDISK or HARDDISK, then the command only drops matching grid disks on the specified media type.

  • The PREFIX option must be specified when ALL is used.

    The PREFIX option specifies one or more comma-separated prefix strings, which are used to identify the grid disks being dropped.

  • If any of the grid disks are in use when DROP GRIDDISK is issued, then an error is reported. You can use ALTER GRIDDISK with the INACTIVE option to deactivate a grid disk before dropping the grid disk. This action ensures that the grid disk is not in use.

  • The FORCE option can be used to force the drop of a grid disk that is in use.

  • If you drop a flash-based grid disk, the space is not automatically allocated to FLASHCACHE. You can use the CREATE FLASHCACHE command to reuse the dropped area for FLASHCACHE.

  • The ERASE option erases the content on the disk by overwriting the content. The values are as follows:

    • 1pass: One pass, and the content is overwritten with zeros. This value is not available for flash drives.

    • 3pass: Three passes, and the disk is overwritten with set data patterns. This option follows the recommendations from NSA. This value is not available for flash drives.

    • 7pass: Seven passes, and the disk is overwritten with set data patterns. This option follows the recommendations from DOD.

  • DROP GRIDDISK ERASE cannot be used for PMEM grid disks.

  • When dropping all grid disks using the 1pass or 3pass option, it necessary to drop the flash disks first using the 7pass option, and then drop the grid disks. The following is an example of the commands: 

    CellCLI> DROP GRIDDISK ALL FLASHDISK PREFIX=data, ERASE=7pass 
CellCLI> DROP GRIDDISK ALL PREFIX=data, ERASE=1pass

  • Use the NOWAIT option with the ERASE option to run the command asynchronously.

Example 7-129 Examples of Dropping a Grid Disk

CellCLI> ALTER GRIDDISK data01_CD_03_cell01 INACTIVE

CellCLI> DROP GRIDDISK data01_CD_03_cell01

CellCLI> DROP GRIDDISK ALL PREFIX=data01

CellCLI> DROP GRIDDISK data02_CD_04_cell01 FORCE

CellCLI> DROP GRIDDISK data02_CD_04_cell01 ERASE=1pass
GridDisk data02_CD_04_cell01 successfully dropped 

CellCLI> DROP GRIDDISK ALL FLASHDISK PREFIX=DATA ERASE=7pass
CellCLI> DROP GRIDDISK ALL PREFIX=DATA ERASE=3pass
7.7.6.7 DROP PMEMCACHE

Purpose

The DROP PMEMCACHE command removes the PMEM Cache from a cell.

Note:

The DROP PMEMCACHE command can only be used on Exadata X8M and X9M storage server models.

Syntax

DROP PMEMCACHE

Usage Notes

  • If the PMEM Cache is in write-back mode, then before dropping the PMEM cache, any data not synchronized with the grid disk (dirty data) must be flushed from PMEM cache to the disks. Failure to flush dirty data can cause data loss.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, you can interchangeably use DROP XRMEMCACHE instead of DROP PMEMCACHE.

Example 7-130 Removing PMEM Cache from a Storage Server

DROP PMEMCACHE

Parent topic: DROP

7.7.6.8 DROP PMEMLOG

Purpose

The DROP PMEMLOG command removes PMEM log from a cell disk.

Note:

The DROP PMEMLOG command can only be used on Exadata X8M and X9M storage server models.

Syntax

DROP PMEMLOG [FORCE]

Usage Notes

  • You can use the DROP PMEMLOG command at run-time, but the command does not complete until all redo data on PMEM is flushed to disk.

  • If FORCE is not specified, then the DROP PMEMLOG command fails if there is any saved redo. If FORCE is specified, then all data is purged, and PMEM log is removed.

    Caution:

    If you are unable to drop the PMEM log due to existing redo information in the log, then retry the command first, before using the FORCE option. The FORCE option should only be used in extreme circumstances because it may cause redo log copies to be out of sync, possibly resulting in database redo data corruption. Contact Oracle Support Services for additional information.

  • On Exadata X8M and X9M systems with Oracle Exadata System Software release 23.1.0, you can interchangeably use DROP XRMEMLOG instead of DROP PMEMLOG.

Example 7-131 Removing PMEM Log from a Storage Server

This example shows how to remove PMEM log from a storage server.

CellCLI> DROP PMEMLOG

Parent topic: DROP

7.7.6.9 DROP QUARANTINE

Purpose

The DROP QUARANTINE command manually drops a quarantine.

Syntax

DROP QUARANTINE { ALL | quarantine1 [, quarantine2]... }

Usage Notes

In general, a quarantine can be removed if the quarantined entity is not expected to cause more problem to CELLSRV. For example, cell offload for problem SQL statements is disabled, or an Oracle Database patch is applied. Refer to the alert message for the quarantine for more details.

When a cell is patched, all quarantines are automatically dropped. It is not necessary to drop them manually.

Examples

The following example shows the DROP QUARANTINE command.

Example 7-132 Dropping Quarantines

CellCLI> DROP QUARANTINE 1

Parent topic: DROP

7.7.6.10 DROP ROLE

Purpose

The DROP ROLE command removes user roles from the cell.

Syntax

DROP ROLE  { ALL | role_name1 [, role_name2, ...]} [FORCE]

Usage Notes

The FORCE option drops the role when the role has been granted to a user.

Examples

The following example shows how to drop a role.

Example 7-133 Dropping a Role

CellCLI>DROP ROLE gd_monitor

Parent topic: DROP

7.7.6.11 DROP SOFTWAREHISTORY

Purpose

The DROP SOFTWAREHISTORY command removes all history or individual update history.

Syntax

DROP SOFTWAREHISTORY { ALL | 'update_name[,update_name...]'}

Example 7-134 Dropping the History of Scheduled Software Updates

CellCLI> DROP SOFTWAREHISTORY '12.2.1.2.0.170509,12.2.1.2.0.17052'

CellCLI> DROP SOFTWAREHISTORY ALL

Parent topic: DROP

7.7.6.12 DROP THRESHOLD

Purpose

The DROP THRESHOLD command removes all or the specified thresholds from the cell.

Syntax

DROP THRESHOLD { ALL |threshold_name [, threshold_name ...] }

Examples

The following example shows the DROP THRESHOLD command.

Example 7-135 Dropping Thresholds

CellCLI> DROP THRESHOLD ct_io_wt_rq.interactive

CellCLI> DROP THRESHOLD ALL

Related Topics

Parent topic: DROP

7.7.6.13 DROP USER

Purpose

The DROP USER command removes a user from a cell.

Syntax

DROP USER { ALL | user1 [, user2]... }

Examples

The following example shows how to drop a user.

Example 7-136 Dropping a User

CellCLI>DROP USER agarcia

Parent topic: DROP

7.7.6.14 DROP XRMEMCACHE

Purpose

Starting with Exadata X10M, the DROP XRMEMCACHE command removes the Exadata RDMA Memory Cache (XRMEM cache).

Note:

On Exadata X8M and X9M systems, the DROP XRMEMCACHE command is equivalent to the DROP PMEMCACHE command.

Syntax

DROP XRMEMCACHE

Usage Notes

Starting with Exadata X10M, the XRMEM cache is re-created automatically during Cell Server (CELLSRV) startup if it does not exist on supported storage servers.

Parent topic: DROP

7.7.6.15 DROP XRMEMLOG

Purpose

Starting with Oracle Exadata System Software release 23.1.0, the DROP XRMEMLOG command is equivalent to the DROP PMEMLOG command.

Note:

The DROP XRMEMLOG command can only be used on Exadata X8M and X9M storage server models.

Parent topic: DROP

7.7.7 EXIT

Purpose

The EXIT command exits from the CellCLI utility, and returns control to the operating system prompt.

Syntax

EXIT

EXIT has the same functionality as the QUIT command.

Parent topic: CellCLI Command Reference

7.7.8 EXPORT CELLDISK

Purpose

The EXPORT CELLDISK command prepares all cell disks or a specified cell disk before moving (importing) the cell disk to a different cell.

Syntax

EXPORT CELLDISK { ALL | cdisk_name }

Usage Notes

To move a cell disk from one cell to another, use the EXPORT CELLDISK and IMPORT CELLDISK commands. Usually, all disks are moved to a new cell if the current cell is failing. First, export the cell disk on one cell. Then, import the exported cell disk using the CellCLI utility on the cell where you moved the physical drive that contains the cell disk.

Using cell disk export and import does not preserve the security configuration details associated with ASM-scoped or DB-scoped security. Consequently, after a successful cell disk export and import, you must remove and reconfigure ASM-scoped or DB-scoped security.

When the EXPORT CELLDISK command is run:

  • ALL exports all cell disks on the cells that have normal status.

  • If the LUN associated with the cell disk is flagged as automatically-created, then that LUN is deleted as part of the export.

  • A successfully exported cell disk has the status attribute set to ImportRequired, and the exported cell disk is displayed in the output of the LIST CELLDISK command.

  • The following apply when a cell disk is exported (status='ImportRequired') before it is imported:

    • You can change the name and comment attributes.

    • You can drop the cell disk.

    • You cannot create a new grid disk on the cell disk.

  • When a disk is exported, any writes from the disk controller cache to the disk are cleared, and the disk is flagged to indicate that the disk was exported. The grid disks on the disk are no longer visible to Oracle ASM. Any I/Os to the grid disks get errors.

Before exporting a cell disk, the data not synchronized with the grid disk (dirty data) must be flushed from flash cache to the grid disks. Not flushing dirty data may cause data loss.

Examples

The following example shows the EXPORT CELLDISK command.

Example 7-137 Exporting a Cell Disk

CellCLI> EXPORT CELLDISK CD_3_cell01

CellCLI> EXPORT CELLDISK ALL

Related Topics

Parent topic: CellCLI Command Reference

7.7.9 GRANT

Purpose

The GRANT command sets attributes for privileges and roles.

Syntax

GRANT object_type [name] TO sub_object_type [sub_object_name]

Usage Notes

  • object_type can be as follows:

    • PRIVILEGE
    • ROLE

  • The following values can be used for PRIVILEGE object type:

    • name is in the following format: 

      { ALL ACTIONS |