Oracle 1Z0-058 Online Practice Questions and Exam Preparation

Oracle 1Z0-058 Online Questions & Answers

• Question 1:

  Which interconnect design is NOT supported for Oracle Clusterware?

  A. crossover cable design
  B. single switch design
  C. multiple switch design
  D. redundant interconnect design
  A. crossover cable design

  ---

  2.7.1 Network Hardware Requirements

  For the private network, the interface must support the user datagram protocol (UDP) using high- speed network adapters and switches that support TCP/IP (minimum requirement 1 Gigabit Ethernet).

  Note:

  UDP is the default interface protocol for Oracle RAC, and TCP is the interconnect protocol for Oracle Clusterware. You must use a switch for the interconnect. Oracle recommends that you use a dedicated switch.

  Oracle does not support token-rings or crossover cables for the interconnect.

  Oracle?Grid Infrastructure Installation Guide 11g Release 2 (11.2)

• Question 2:

  You are managing a three-instance policy-managed RAC database PROD. You created a service called GL for the PROD database by using the following command:

  [oracIe@gr7597~]$ srvctl add service -d PROD -s GL -g SP1 -c singleton -y manual Examine the following output: [oracIe@gr7597~]$ srvctl config database -d PROD -a Database unique name: PROD Database name: PROD Oracle home: /u01/app/oracle/product/11.2.0/dbhome_1 Oracle user: oracle Spfile: +DATA/PROD/spfileRACDB.ora Domain: Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Server pools: SP1 Database instances: Disk Groups: DATA, FRA Services: Database is enabled Database is policy managed [oracIe@gr7597~]$ crsctl stat res ora.PROD.db NAME=ora.PROD.db TYPE=cluster_resource TARGET=ONLINE STATE=ONLINE on gr7597 ONLINE on gr7602 ONLINE on gr7633 [oracIe@gr7597~]$ crsctl stat serverpool ora.SP1 NAME=ora.SP1 ACTIVE_SERVERS=gr7597 gr7602 gr7633 [oracle甮r7597-]$ crsctl stat res ora.prod.gl.svc NAME=ora.prod.gl.svc TYFE=ora.service.type TARGET=ONLINE STATE=ONLINE on gr7597 Which three steps are required to enable ODP.NET clients that connect to the GL service to receive FAN High Availability Events?

  A. Enable Advanced Queuing notifications by using SRVCTL as shown in the following command: $ srvctl modify service -d prod -s gl -q TRUE -j LONG
  B. Execute the following statement for the users that will be connecting by way of the .Net Application, where user_name is the user name: EXECUTE DBMS_AQADM.GRANT_QUEUE_PRIVILEGE( 'DEQUEUE', ' SYS.SYS$SERVICE_METRICS', user_name ) ;
  C. Enable Transparent Application Failover (TAF), either on the client or for the service.
  D. Enable Fast Connection Failover for ODP.NET connection pools by subscribing to FAN High Availability events. Do this by setting the HA events connection string attribute to true at connection time.
  E. Link client applications with the client thread or operating system library.
  A. Enable Advanced Queuing notifications by using SRVCTL as shown in the following command: $ srvctl modify service -d prod -s gl -q TRUE -j LONG
  B. Execute the following statement for the users that will be connecting by way of the .Net Application, where user_name is the user name: EXECUTE DBMS_AQADM.GRANT_QUEUE_PRIVILEGE( 'DEQUEUE', ' SYS.SYS$SERVICE_METRICS', user_name ) ;
  D. Enable Fast Connection Failover for ODP.NET connection pools by subscribing to FAN High Availability events. Do this by setting the HA events connection string attribute to true at connection time.

  ---

  Enabling ODP.NET Clients to Receive FAN High Availability Events Perform the following steps to enable FAN for ODP.NET clients:

  Enable Advanced Queuing notifications for a service by using SRVCTL as shown in the following example:

  srvctl modify service -d crm -s odpnet.example.com -q TRUE Grant permissions on the internal event queue table by executing the following command for the users that will be connecting by way of the ODP.NET application, where

  user_name is the database user name:

  EXECUTE

  DBMS_AQADM.GRANT_QUEUE_PRIVILEGE('DEQUEUE','SYS.SYS$SERVICE_METRI CS', user_name);

  Enable Fast Connection Failover for ODP.NET connection pools by subscribing to FAN high availability events. To enable FCF, include "HA Events=true" and "pooling=true" (the default value) in the connection string, as shown in the

  following example where user_name is the name of the database user and password is the password for that user:

  con.ConnectionString =

  "User Id=user_name;Password=password;Data Source=odpnet;" + "Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" + "HA Events=true;Incr Pool Size=5;Decr Pool Size=2";

  Oracle?Real Application Clusters Administration and Deployment Guide 11g Release 2 (11.2)

• Question 3:

  You are managing a single-instance database and your company wants to convert the single instance database to an Oracle RAC database. You plan to use the rconfig utility to accomplish this task.

  What are the prerequisites for converting the single-instance database to an Oracle RAC database?

  A. Oracle Clusterware and Oracle Database software are installed on all target nodes.
  B. The Oracle Database binary is enabled for Oracle RAC on all target nodes.
  C. The database being converted has been backed up successfully.
  D. Oracle Clusterware is stopped.
  E. Automatic Storage Management (ASM) must be enabled and the ASM disk should be available on all nodes.
  C. The database being converted has been backed up successfully.

  ---

  C.3.1 Prerequisites for Converting to Oracle RAC Databases Before you convert a single-instance database to an Oracle RAC database, ensure that the following conditions are met for each cluster node that you intend to make an Oracle RAC database node:

  Oracle Clusterware 11g release 2 (11.2) is installed, configured, and running. Oracle RAC 11g release 2 (11.2) software is installed.

  The Oracle binary is enabled for Oracle RAC.

  Shared storage, either Oracle Cluster File System or Oracle ASM, is available and accessible from all nodes.

  User equivalence exists for the oracle account.

  If you intend to use Oracle Enterprise Manager, then all Oracle Enterprise Manager agents are configured and running, and are configured with cluster and host information.

  You have backed up your existing database.

  Oracle?Real Application Clusters Installation Guide 11g Release 2 (11.2) for Linux and UNIX

• Question 4:

  Your cluster was originally created with nodes RACNODE1 and RACNODE2 three years ago. Last year, nodes RACNODE3 and RACNODE4 were added.

  These nodes have faster processors and more local storage than the original nodes making performance management and tuning more difficult.

  Two more nodes with the same processor speed have been added to the cluster last week as RACNODE5 and RACNODE6 and you must remove RACNODE1 and RACNODE2 for redeployment.

  The Oracle Grid Infrastructure is using GNS and the databases are all 11g Release 2, all running from the same home. The Grid home is /fs01/home/grid.

  Which three steps must be performed to remove the nodes from the cluster?

  A. Run /fs01/home/grid/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/fs01/home/grid "CLUSTER_NODES= {RACNODE3 , RACNODE4 , RACNODE5 , RACNODE6} as the grid software owner on any remaining node.
  B. Run /fs01/home/grid/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/fs01/home/grid " CLUSTER_NODES={RACNODE1} as the grid software owner on RACNODE1 and run /fs01/home/ grid/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/ fs01/home/grid " CLUSTER_NODES={RACNODE 2} as the grid software owner on RACNODE2.
  C. Run /fs01/home/grid/oui/bin/runInstaller -detachHome ORACLE_HOME=/fs01/home/grid as the grid software owner on RACNODE1 and RACNODE2.
  D. Run the /fs01/home/grid/crs/install/rootcrs.pl script as root on each node to be deleted.
  E. Run crsctl delete node -n RACNODE1 and crsctl delete node -n RACNODE2 as root from any node remaining in the cluster.
  A. Run /fs01/home/grid/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/fs01/home/grid "CLUSTER_NODES= {RACNODE3 , RACNODE4 , RACNODE5 , RACNODE6} as the grid software owner on any remaining node.
  D. Run the /fs01/home/grid/crs/install/rootcrs.pl script as root on each node to be deleted.
  E. Run crsctl delete node -n RACNODE1 and crsctl delete node -n RACNODE2 as root from any node remaining in the cluster.

  ---

  Deleting a Cluster Node on Linux and UNIX Systems

  1.

  Ensure that Grid_home correctly specifies the full directory path for the Oracle Clusterware home on each node, where Grid_home is the location of the installed Oracle Clusterware software.

  2.

  Run the following command as either root or the user that installed Oracle Clusterware to determine whether the node you want to delete is active and whether it is pinned:

  $ olsnodes -s -t

  If the node is pinned, then run the crsctl unpin css command. Otherwise, proceed to the next step.

  3.

  Disable the Oracle Clusterware applications and daemons running on the node. Run the rootcrs.pl script as root from the Grid_home/crs/install directory on the node to be deleted, as follows:

  # ./rootcrs.pl -deconfig -deinstall -force

  If you are deleting multiple nodes, then run the rootcrs.pl script on each node that you are deleting. If you are deleting all nodes from a cluster, then append the -lastnode option to the preceding command to clear OCR and the voting disks, as follows: # ./rootcrs.pl -deconfig -deinstall -force -lastnode

  4.

  From any node that you are not deleting, run the following command from the Grid_home/bin directory as root to delete the node from the cluster:

  # crsctl delete node -n node_to_be_deleted

  Then if you run a dynamic Grid Plug and Play cluster using DHCP and GNS, skip to step 7.

  5.

  On the node you want to delete, run the following command as the user that installed Oracle Clusterware from the Grid_home/oui/bin directory where node_to_be_deleted is the name of the node that you are deleting:

  $ ./runInstaller -updateNodeList ORACLE_HOME=Grid_home "CLUSTER_NODES= {node_to_be_deleted}" CRS=TRUE -silent -local

  6.

  On the node that you are deleting, depending on whether you have a shared or local Oracle home, complete one of the following procedures as the user that installed Oracle Clusterware:

  If you have a shared home, then run the following command from the Grid_home/oui/bin directory on the node you want to delete:

  $ ./runInstaller -detachHome ORACLE_HOME=Grid_home -silent -local For a local home, deinstall the Oracle Clusterware home from the node that you want to delete, as follows, by running the following command, where Grid_home is the

  path defined for the Oracle Clusterware home:

  $ Grid_home/deinstall/deinstall local

  7.

  On any node other than the node you are deleting, run the following command from the Grid_home/oui/ bin directory where remaining_nodes_list is a comma-delimited list of the nodes that are going to remain part of your cluster:

  $ ./runInstaller -updateNodeList ORACLE_HOME=Grid_home "CLUSTER_NODES= {remaining_nodes_list}" CRS=TRUE -silent

  8.

  Run the following CVU command to verify that the specified nodes have been successfully deleted from the cluster:

  $ cluvfy stage -post nodedel -n node_list [-verbose]

  Oracle?Clusterware Administration and Deployment Guide 11g Release 2 (11.2)

• Question 5:

  Your RAC database has a high volume of inserts into the SALES table. Sequence SALES_SEQ is used to generate primary key values. Examine the following query output:

  SQL> SELECT sequence_name, min_value, max_value, increment_by, cache_size FROM dba_sequences ;

  Output:

  

  What would you recommend to improve the response times?

  A. Increasing size of undo tablespaces
  B. increasing sequence cache sizes
  B. increasing sequence cache sizes

  ---

  Oracle Sequences and Index Contention Indexes with key values generated by sequences tend to be subject to leaf block contention when the insert rate is high. That is because the index leaf block holding the highest key value is changed for every row inserted, as the values are monotonically ascending. In RAC, this may lead to a high rate of current and CR blocks transferred between nodes. One of the simplest techniques that can be used to limit this overhead is to increase the sequence cache, if you are using Oracle sequences. Because the difference between sequence values generated by different instances increases, successive index block splits tend to create instance affinity to index leaf blocks. For example, suppose that an index key value is generated by a CACHE NOORDER sequence and each index leaf block can hold 500 rows. If the sequence cache is set to 50000, while instance 1 inserts values 1, 2, 3, and so on, instance 2 concurrently inserts 50001, 50002, and so on. After some block splits, each instance writes to a different part of the index tree. So, what is the ideal value for a sequence cache to avoid inter-instance leaf index block contention, yet minimizing possible gaps? One of the main variables to consider is the insert rate: the higher it is, the higher must be the sequence cache. However, creating a simulation to evaluate the gains for a specific configuration is recommended. Note: By default, the cache value is 20. Typically, 20 is too small for the preceding example.

  D60488GC11 Oracle 11g: RAC and Grid Infrastructure Administration Accelerated 14 24

• Question 6:

  On the OUI Grid Plug and Play information page, you can configure GRID Naming Service (GNS). What will be the SCAN Name field default to if you enter cluster01 in the cluster Name field and cluster01.example.com in the GNS Sub Domain field?

  A. cluster01.example.com
  B. cluster01-qns.example.com
  C. cluster01-scan.cluster01.example.com
  D. cluster-vip.example.com
  C. cluster01-scan.cluster01.example.com

  ---

  If you specify a GNS domain, then the SCAN name defaults to clustername-scan.GNS_domain. Otherwise, it defaults to clustername-scan.current_domain. For example, if you start Oracle Grid Infrastructure installation from the server node1,

  the cluster name is mycluster, and the GNS do- main is grid.example.com, then the SCAN Name is mycluster-scan.grid.example.com.

  Oracle Grid Infrastructure Installation Guide

• Question 7:

  You installed the Oracle Grid Infrastructure on a four-node cluster before discussing the network requirements with the network administrator who was on holiday.

  You created a single scan named mydb-scan.myclust.example.com by adding this name to the /etc/hosts file. As a result, the Grid Infrastructure has four node listeners and node VIP but only a single SCAN listener and SCAN VIP. The network administrator has returned and modified the corporate DNS server to associate three IP addresses with the mydb-scan.myclust.example.com scan name. The SCAN VIPs are on the same network as the node VIPs. You now must replace the single SCAN VIP and listener with three of each for high availability purposes and make certain that the SCANs and listeners are active. Which procedure will do this properly if run as the root user?

  A. srvctl stop scan_listener srvctl stop scan srvctl start scan srvctl start scan_listener
  B. srvctl stop scan_listener srvctl stop scan srvctl remove scan srvctl add scan -n MYDB-SCAN.MYCLUST.EXAMPLE.COM srvctl start scan srvctl start scan_listener
  C. srvctl add scan -n MYDB-SCAN.MYCLUST.EXAMPLE.COM srvctl start scan srvctl start scan_listener
  D. srvctl stop scan_listener srvctl stop scan srvctl remove scan srvctl add scan srvctl start scan srvctl start scan listener
  B. srvctl stop scan_listener srvctl stop scan srvctl remove scan srvctl add scan -n MYDB-SCAN.MYCLUST.EXAMPLE.COM srvctl start scan srvctl start scan_listener

  ---

  How to update the IP address of the SCAN VIP resources (ora.scan.vip) [ID 952903.1] Modified 03-JAN- 2012 Type HOWTO Status PUBLISHED

  In this Document

  Goal

  Solution

  Applies to:

  Oracle Server - Enterprise Edition - Version: 11.2.0.1 to 11.2.0.1 - Release: 11.2 to 11.2 Information in this document applies to any platform.

  Goal

  The purpose of this document is to explain how to change the IP addresses associated with the SCAN VIPs in a 11gR2 Grid (CRS) environment.

  The IP addresses associated with the SCAN VIP resources are initially set when the SCAN resources are created.

  Any changes to the DNS entry for the SCAN are not automatically propagated to the clusterware and need to be done manually.

  This applies only to installations that are not using GNS. The information in this note can also be helpful in cases where SCAN was originally configured with just one address and is now being expanded to accommodate three IP addresses.

  Solution

  Before the SCAN VIPs can be changed, the entry for the SCAN name on the Domain Name Server (DNS) needs to be updated with the new IP addresses. This usually will be done by a network administrator. To check the current setting, the

  following command can be used:

  nslookup

  To check the current IP address(es) of the SCAN VIPs, run the following commands as the root user:

  $GRID_HOME/bin/srvctl config scan

  Next refresh the SCAN VIPs with the new IP addresses from the DNS entry:

  $GRID_HOME/bin/srvctl modify scan -n

  To check if the SCAN VIPs have been changed, run the following command, it should now show the new IP addresses.

  $GRID_HOME/bin/srvctl config scan

  Below is an example using the following configuration:

  The name of the SCAN is sales-scan.example.com

  subnet of the public network is 10.100.10.0

  netmask for the public network is 255.255.255.0

  name of the public interface is eth1

  old IP addresses: 10.100.10.81, 10.100.10.82 and 10.100.10.83 new IP addresses: 10.100.10.121, 10.100.10.122 and 10.100.10.123

  A lookup of the SCAN on the DNS server shows that the entry has already been updated with the new IP addresses:

  $ nslookup sales-scan.example.com

  Server: dns1.example.com

  Address: 10.100.10.70#53

  Name: sales-scan.example.com

  Address: 10.100.10.123

  Name: sales-scan.example.com

  Address: 10.100.10.122

  Name: sales-scan.example.com

  Address: 10.100.10.121

  Stop the SCAN listener and the SCAN VIP resources:

  # $GRID_HOME/bin/srvctl stop scan_listener

  # $GRID_HOME/bin/srvctl stop scan

  # $GRID_HOME/bin/srvctl status scan

  SCAN VIP scan1 is enabled

  SCAN VIP scan1 is not running

  SCAN VIP scan2 is enabled

  SCAN VIP scan2 is not running

  SCAN VIP scan3 is enabled

  SCAN VIP scan3 is not running

  # $GRID_HOME/bin/srvctl status scan_listener

  SCAN Listener LISTENER_SCAN1 is enabled

  SCAN listener LISTENER_SCAN1 is not running

  SCAN Listener LISTENER_SCAN2 is enabled

  SCAN listener LISTENER_SCAN2 is not running

  SCAN Listener LISTENER_SCAN3 is enabled

  SCAN listener LISTENER_SCAN3 is not running

  The SCAN VIP resources still show the old IP addresses:

  # $GRID_HOME/bin/srvctl config scan

  SCAN name: sales-scan, Network: 1/10.100.10.0/255.255.255.0/eth1 SCAN VIP name: scan1, IP: /sales- scan.example.com/10.100.10.81 SCAN VIP name: scan2, IP: /sales-scan.example.com/10.100.10.82 SCAN VIP name: scan3, IP: /

  sales-scan.example.com/10.100.10.83

  Now tell CRS to update the SCAN VIP resources:

  # $GRID_HOME/bin/srvctl modify scan -n sales-scan.example.com

  To verify that the change was successful, check the SCAN configuration again:

  # $GRID_HOME/bin/srvctl config scan

  SCAN name: sales-scan, Network: 1/10.100.10.0/255.255.255.0/eth1 SCAN VIP name: scan1, IP: /sales- scan.example.com/10.100.10.121 SCAN VIP name: scan2, IP: /sales-scan.example.com/10.100.10.122 SCAN VIP name: scan3, IP: /

  sales-scan.example.com/10.100.10.123 Start SCAN and the SCAN listener:

  # $GRID_HOME/bin/srvctl start scan

  # $GRID_HOME/bin/srvctl start scan_listener

  Please note that if the SCAN VIPs are being changed because of a change of the subnet of the public network additional changes may be required , e.g. the node VIPs and the network resource (ora.net1.network). For more information

  please refer to Document 276434.1 and the 11.2 documentation.

  My Oracle Support

• Question 8:

  The System Global Area (SGA) for the ASM instance contains distinct memory areas. Choose three areas that are contained within the ASM SGA.

  A. Shared Pool
  B. Buffer Cache
  C. Log Buffer
  D. Large Pool
  E. ASM Cache
  F. Streams Pool
  A. Shared Pool
  D. Large Pool
  E. ASM Cache

  ---

  Section: (none) The SGA in an ASM instance is different in memory allocation and usage than the SGA in a database instance. The SGA in the ASM instance is divided into four primary areas as follows: Shared Pool: Used for metadata information Large Pool: Used for parallel operations ASM Cache: Used for reading and writing blocks during rebalance operations Free Memory: Unallocated memory available D60488GC11 Oracle 11g: RAC and Grid Infrastructure Administration

• Question 9:

  During the installation of Oracle Grid Infrastructure 11.2, it is possible to incorporate failure isolation support by using Intelligent Platform Management Interface (IPMI). Which four statements regarding IPMI configuration are true?

  A. Each cluster member node requires a Baseboard Management Controller (BMC), which runs a firmware compatible with IPMI version 1.5.
  B. The ethernet port on each cluster node used by BMC must be connected to the IPMI management network.
  C. Each node in the cluster must have an IPMI driver installed.
  D. The cluster requires a dedicated network specifically for IPMI.
  E. If you intend to use IPMI, you must provide an administration account username and password when prompted during installation.
  A. Each cluster member node requires a Baseboard Management Controller (BMC), which runs a firmware compatible with IPMI version 1.5.
  B. The ethernet port on each cluster node used by BMC must be connected to the IPMI management network.
  C. Each node in the cluster must have an IPMI driver installed.
  E. If you intend to use IPMI, you must provide an administration account username and password when prompted during installation.

  ---

  2.13.1 Requirements for Enabling IPMI

  You must have the following hardware and software configured to enable cluster nodes to be managed with IPMI:

  Each cluster member node requires a Baseboard Management Controller (BMC) running firmware compatible with IPMI version 1.5 or greater, which supports IPMI over LANs, and configured for remote control using LAN.

  Each cluster member node requires an IPMI driver installed on each node. The cluster requires a management network for IPMI. This can be a shared network, but Oracle recommends that you configure a dedicated network. Each cluster

  member node's Ethernet port used by BMC must be connected to the IPMI management network.

  Each cluster member must be connected to the management network. Some server platforms put their network interfaces into a power saving mode when they are powered off. In this case, they may operate only at a lower link speed (for

  example, 100 MB, instead of 1 GB). For these platforms, the network switch port to which the BMC is connected must be able to auto-negotiate down to the lower speed, or IPMI will not function properly.

  Have IPMI Configuration completed and have IPMI administrator account information If you intend to use IPMI, then ensure BMC interfaces are configured, and have an administration account username and password to provide when

  prompted during installation. For nonstandard installations, if you must change configuration on one or more nodes after installation (for example, if you have different administrator usernames and passwords for BMC interfaces on cluster

  nodes), then decide if you want to reconfigure the BMC interface, or modify IPMI administrator account information after installation.

  Oracle?Grid Infrastructure Installation Guide 11g Release 2 (11.2) for Linux

• Question 10:

  You want to reorganize the DATA diskgroup while continuing database operations. The DATA diskgroup was created using normal redundancy having one disk per failure group. The two disks used are /dev/sdal and /dev/sda2.

  You plan to drop the existing disks and add the /dev/sdb1 and /dev/sdb2 disks to failure group FG_C and the /dev/sdcl and /dev/sdc2 disks to failure group FG_D.

  Which procedure would you use to minimize the effect of the I/Os of this reorganization on ongoing database operations?

  A. Set rebalance power to 0 for diskgroup DATA. Add failure group FG_C with all the /dev/sdb disks. Add failure group FG_D with all the /dev/sdc disks. Drop disks/dev/sda1 and /dev/sda2. Set rebalance power to 1 for diskgroup DATA.
  B. Set rebalance power to 0 for diskgroup DATA. Add failure group FG_C with all the /dev/sdb disks. Add failure group FG_D with all the /dev/sdb disks. Drop disks/dev/sda1 and /dev/sda2. Set rebalance power to 9 for diskgroup DATA.
  C. Set rebalance power to 9 for diskgroup DATA. Add failure group FG_C with all the /dev/sdb disks. Add failure group FG_D with all the /dev/sdc disks. Drop disks /dev/sda1 and /dev/sda2. Set rebalance power to 0 for diskgroup DATA.
  D. Set rebalance power to 0 for diskgroup DATA Drop disks /dev/sdal and /dev/sdb disks. Add failure group FG_C with all the /dev/sdb disks. Add failure group FG_D with all the /dev/sdc disks Set rebalance power to 1 for diskgroup DATA.
  A. Set rebalance power to 0 for diskgroup DATA. Add failure group FG_C with all the /dev/sdb disks. Add failure group FG_D with all the /dev/sdc disks. Drop disks/dev/sda1 and /dev/sda2. Set rebalance power to 1 for diskgroup DATA.

  ---

  To control the speed and resource consumption of the rebalance operation, you can in- clude the REBALANCE POWER clause in statements that add, drop, or resize disks. The ASM_POWER_LIMIT initialization parameter specifies the default power for disk rebalancing in a disk group. The range of values is 0 to 1024. The default value is 1. A value of 0 disables rebalancing. Higher numeric values enable the rebalancing operation to complete more quickly, but might result in higher I/O overhead and more rebalancing processes. Failure groups are used to place mirrored copies of data so that each copy is on a disk in a different failure group. The simultaneous failure of all disks in a failure group does not result in data loss. You define the failure groups for a disk group when you create an Oracle ASM disk group. After a disk group is created, you cannot alter the redundancy level of the disk group. If you omit the failure group specification, then Oracle ASM automatically places each disk into its own failure group, except for disk groups containing disks on Oracle Exadata cells. Normal redundancy disk groups require at least two failure groups. High redundancy disk groups require at least three failure groups. Disk groups with external redundancy do not use failure groups. Oracle?Automatic Storage Management