57 Sharded Database Lifecycle Management
Oracle Sharding provides tools and some automation for lifecycle management of a sharded database.
The following topics describe sharded database lifecycle management in detail:
- Monitoring a Sharded Database
Sharded databases can be monitored using Enterprise Manager Cloud Control or GDSCTL. - Backing Up and Recovering a Sharded Database
Because shards are hosted on individual Oracle databases, you can use Oracle Maximum Availability best practices to back up and restore shards individually. - Patching a Sharded Database
Applying an Oracle patch to a sharded database environment can be done on a single shard or all shards; however, the method you use depends on the replication option used for the environment and the type of patch being applied. - Modifying a Sharded Database Schema
When making changes to duplicated tables or sharded tables in a sharded database, these changes should be done from the shard catalog database. - Shard Management
You can manage shards in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control and GDSCTL. - Chunk Management
You can manage chunks in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control and GDSCTL. - Shard Director Management
You can add, edit, and remove shard directors in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control. - Region Management
You can add, edit, and remove regions in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control. - Shardspace Management
You can add, edit, and remove shardspaces in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control. - Shardgroup Management
You can add, edit, and remove shardgroups in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control. - Services Management
You can manage services in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control.
57.1 Monitoring a Sharded Database
Sharded databases can be monitored using Enterprise Manager Cloud Control or GDSCTL.
See the following topics to use Enterprise Manager Cloud Control or GDSCTL to monitor sharded databases.
- Monitoring a Sharded Database with GDSCTL
There are numerousGDSCTL CONFIG
commands that you can use to obtain the health status of individual shards, shardgroups, shardspaces, and shard directors. - Monitoring a Sharded Database with Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control lets you discover, monitor, and manage the components of a sharded database.
57.1.1 Monitoring a Sharded Database with GDSCTL
There are numerous GDSCTL CONFIG
commands that you can use to obtain the health status of individual shards, shardgroups, shardspaces, and shard directors.
Monitoring a shard is just like monitoring a normal database, and standard Oracle best practices should be used to monitor the individual health of a single shard. However, it is also important to monitor the overall health of the entire sharded environment. The GDSCTL commands can also be scripted and through the use of a scheduler and can be done at regular intervals to help ensure that everything is running smoothly.
See Also:
Oracle Database Global Data Services Concepts and Administration Guide for information about using the GDSCTL CONFIG
commands
57.1.2 Monitoring a Sharded Database with Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control lets you discover, monitor, and manage the components of a sharded database.
Sharded database targets are found in the All Targets page.
Figure 57-1 Sharded Databases in the All Targets Refine Search pane
![Description of Figure 57-1 follows Description of Figure 57-1 follows](img/shard_em_alltargets.png)
Description of "Figure 57-1 Sharded Databases in the All Targets Refine Search pane"
The target home page for a sharded database shows you a summary of the sharded database components and their statuses.
To monitor sharded database components you must first discover them. See Discovering Sharded Database Components for more information.
Summary
The Summary pane, in the top left of the page, shows the following information:
-
Sharded database name
-
Sharded database domain name
-
Shard catalog name. You can click the name to view more information about the shard catalog.
-
Shard catalog database version
-
Sharding method used to shard the database
-
Replication technology used for high availability
-
Number and status of the shard directors
-
Master shard director name. You can click the name to view more information about the master shard director.
Shard Load Map
The Shard Load Map, in the upper right of the page, shows a pictorial graph illustrating how transactions are distributed among the shards.
Figure 57-3 Sharded Database Shard Load Map
![Description of Figure 57-3 follows Description of Figure 57-3 follows](img/shard_em_loadmap.png)
Description of "Figure 57-3 Sharded Database Shard Load Map"
You can select different View Levels above the graph.
-
Database
The database view aggregates database instances in Oracle RAC cluster databases into a single cell labeled with the Oracle RAC cluster database target name. This enables you to easily compare the total database load in Oracle RAC environments.
-
Instance
The instance view displays all database instances separately, but Oracle RAC instances are grouped together as sub-cells of the Oracle RAC database target. This view is essentially a two-level tree map, where the database level is the primary division, and the instance within the database is the secondary division. This allows load comparison of instances within Oracle RAC databases; for instance, to easily spot load imbalances across instances.
-
Pluggable Database
Although the PDB option is shown, PDB is not supported for Oracle Sharding in the current release.
Notice that the cells of the graph are not identical in size. Each cell corresponds to a shard target, either an instance or a cluster database. The cell size (its area) is proportional to the target database's load measured in average active sessions, so that targets with a higher load have larger cell sizes. Cells are ordered by size from left to right and top to bottom. Therefore, the target with the highest load always appears as the upper leftmost cell in the graph.
You can hover your mouse pointer over a particular cell of the graph to view the total active load (I/O to CPU ration), CPU, I/O, and wait times. Segments of the graph are colored to indicate the dominant load:
-
Green indicates that CPU time dominates the load
-
Blue indicates that I/O dominates the load
-
Yellow indicates that WAIT dominates the load
Members
The Members pane, in the lower left of the page, shows some relevant information about each of the components.
The pane is divided into tabs for each component: Shardspaces, Shardgroups, Shard Directors, and Shards. Click on a tab to view the information about each type of component
-
Shardspaces
The Shardspaces tab displays the shardspace names, status, number of chunks, and Data Guard protection mode. The shardspace names can be clicked to reveal more details about the selected shardspace.
-
Shardgroups
The Shardgroups tab displays the shardgroup names, status, the shardspace to which it belongs, the number of chunks, Data Guard role, and the region to which it belongs. You can click the shardgroup and shardspace names to reveal more details about the selected component.
-
Shard Directors
The Shard Directors tab displays the shard director names, status, region, host, and Oracle home. You can click the shard director names can be clicked to reveal more details about the selected shard director.
-
Shards
The Shards tab displays the shard names, deploy status, status, the shardspaces and shardgroups to which they belong, Data Guard roles, and the regions to which they belong. In the Names column, you can expand the Primary shards to display the information about its corresponding Standby shard. You can hover the mouse over the Deployed column icon and the deployment status details are displayed. You can click on the shard, shardspace, and shardgroup names to reveal more details about the selected component.
Services
The Services pane, in the lower right of the page, shows the names, status, and Data Guard role of the sharded database services. Above the list is shown the total number of services and an icon showing how many services are in a particular status. You can hover your mouse pointer over the icon to read a description of the status icon.
Figure 57-5 Sharded Database Services pane
![Description of Figure 57-5 follows Description of Figure 57-5 follows](img/shard_em_services.png)
Description of "Figure 57-5 Sharded Database Services pane"
Incidents
The Incidents pane displays messages and warnings about the various components in the sharded database environment. More information about how to use this pane is in the Cloud Control online help.
Sharded Database Menu
The Sharded Database menu, located in the top left corner, provides you with access to administrate the sharded database components.
Target Navigation
The Target Navigation pane gives you easy access to more details about any of the components in the sharded database.
![Description of shard_em_navicon.png follows Description of shard_em_navicon.png follows](img/shard_em_navicon.png)
Description of the illustration shard_em_navicon.png
Clicking the navigation tree icon on the upper left corner of the page opens the Target Navigation pane. This pane shows all of the discovered components in the sharded database in tree form.
Expanding a shardspace reveals the shardgroups in them. Expanding a shardgroup reveals the shards in that shardgroup.
Any of the component names can be clicked to view more details about them.
- Discovering Sharded Database Components
In Enterprise Manager Cloud Control, you can discover the shard catalog and shard databases, then add the shard directors, sharded databases, shardspaces, and shardgroups using guided discovery.
57.1.2.1 Discovering Sharded Database Components
In Enterprise Manager Cloud Control, you can discover the shard catalog and shard databases, then add the shard directors, sharded databases, shardspaces, and shardgroups using guided discovery.
As a prerequisite, you must use Cloud Control to discover the shard director hosts and the.shard catalog database. Because the catalog database and each of the shards is a database itself, you can use standard database discovery procedures.
Monitoring the shards is only possible when the individual shards are discovered using database discovery. Discovering the shards is optional to discovering a sharded database, because you can have a sharded database configuration without the shards.
When the target discovery procedure is finished, sharded database targets are added in Cloud Control. You can open the sharded database in Cloud Control to monitor and manage the components.
57.2 Backing Up and Recovering a Sharded Database
Because shards are hosted on individual Oracle databases, you can use Oracle Maximum Availability best practices to back up and restore shards individually.
If you are using Data Guard and Oracle Active Data Guard for SDB high availability, be sure to take observers offline and disable Fast Start Failover before taking a primary or standby database offline.
Contact Oracle Support for specific steps to recover a shard in the event of a disaster.
See Also:
Oracle Maximum Availability Architecture for MAA best practices white papers
57.3 Patching a Sharded Database
Applying an Oracle patch to a sharded database environment can be done on a single shard or all shards; however, the method you use depends on the replication option used for the environment and the type of patch being applied.
Most patches can be applied to a single shard at a time; however, some patches should be applied across all shards. Use Oracle’s best practices for applying patches to single shards just as you would a non-sharded database, keeping in mind the replication method that is being used with the SDB. Oracle opatchauto
can be used to apply patches to multiple shards at a time, and can be done in a rolling manner. Data Guard configurations are applied one after another, and in some cases (depending on the patch) you can use Standby First patching. If a patch addresses an issue with multi-shard queries, replication, or the sharding infrastructure, it should be applied to all of the shards in the SDB.
57.4 Modifying a Sharded Database Schema
When making changes to duplicated tables or sharded tables in a sharded database, these changes should be done from the shard catalog database.
Before executing any DDL operations on a sharded database, enable sharded DDL with
ALTER SESSION ENABLE SHARD DDL;
This statement ensures that the DDL changes will be propagated to each shard in the sharded database.
The DDL changes that are propagated are commands that are defined as “schema related,” which include operations such as ALTER TABLE
and CREATE TRIGGER
. There are other operations that are propagated to each shard, such as the CREATE, ALTER, DROP
user commands for simplified user management, and TABLESPACE
operations to simplify the creation of tablespaces on multiple shards.
GRANT
and REVOKE
operations can be done from the shard catalog and are propagated to each shard, providing you have enabled shard DDL for the session. If more granular control is needed you can issue the command directly on each shard.
Operations such as DBMS package calls or similar operations are not propagated. For example, operations gathering statistics on the shard catalog are not propagated to each shard.
If you perform an operation that requires a lock on a table, such as adding a not null column, it is important to remember that each shard needs to obtain the lock on the table in order to perform the DDL operation. Oracle’s best practices for applying DDL in a single instance apply to sharded environments.
Multi-shard queries, which are executed on the shard catalog, issue remote queries across database connections on each shard. In this case it is important to ensure that the user has the appropriate privileges on each of the shards, whether or not the query will return data from that shard.
See Also:
Oracle Database SQL Language Reference for information about operations used with duplicated tables and sharded tables
57.5 Shard Management
You can manage shards in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control and GDSCTL.
The following topics describe shard management concepts and tasks:
- About Adding Shards
New shards can be added to an existing sharded database environment to scale out and to improve fault tolerance. - Resharding and Hot Spot Elimination
The process of redistributing data between shards, triggered by a change in the number of shards, is called resharding. Automatic resharding is a feature of the system-managed sharding method that provides elastic scalability of an SDB. - Removing a Shard From the Pool
It may become necessary to remove a shard from the sharded database environment, either temporarily or permanently, without losing any data that resides on that shard. - Adding Standby Shards
You can add Data Guard standby shards to an Oracle Sharding environment; however there are some limitations. - Managing Shards with Oracle Enterprise Manager Cloud Control
You can manage database shards using Oracle Enterprise Manager Cloud Control - Managing Shards with GDSCTL
You can manage shards in your Oracle Sharding deployment using the GDSCTL command-line utility.
57.5.1 About Adding Shards
New shards can be added to an existing sharded database environment to scale out and to improve fault tolerance.
For fault tolerance, it is beneficial to have many smaller shards than a few very large ones. As an application matures and the amount of data increases, you can add an entire shard or multiple shards to the SDB to increase capacity.
When you add a shard to a sharded database, if the environment is sharded by consistent hash, then chunks from existing shards are automatically moved to the new shard to rebalance the sharded environment.
Oracle Enterprise Manager Cloud Control can be used to help identify chunks that would be good candidates to move, or split and move to the new shard.
When you add a shard to the environment, verify that the standby server is ready, and after the new shard is in place take backups of any shards that have been involved in a move chunk
operation.
57.5.2 Resharding and Hot Spot Elimination
The process of redistributing data between shards, triggered by a change in the number of shards, is called resharding. Automatic resharding is a feature of the system-managed sharding method that provides elastic scalability of an SDB.
Sometimes data in an SDB needs to be migrated from one shard to another. Data migration across shards is required in the following cases:
-
When one or multiple shards are added to or removed from an SDB
-
When there is skew in the data or workload distribution across shards
The unit of data migration between shards is the chunk. Migrating data in chunks guaranties that related data from different sharded tables are moved together.
When a shard is added to or removed from an SDB, multiple chunks are migrated to maintain a balanced distribution of chunks and workload across shards.
Depending on the sharding method, resharding happens automatically (system-managed) or is directed by the user (composite). The following figure shows the stages of automatic resharding when a shard is added to an SDB with three shards.
A particular chunk can also be moved from one shard to another, when data or workload skew occurs, without any change in the number of shards. In this case, chunk migration can be initiated by the database administrator to eliminate the hot spot.
RMAN Incremental Backup, Transportable Tablespace, and Oracle Notification Service technologies are used to minimize impact of chunk migration on application availability. A chunk is kept online during chunk migration. There is a short period of time (a few seconds) when data stored in the chunk is available for read-only access only.
FAN-enabled clients receive a notification when a chunk is about to become read-only in the source shard, and again when the chunk is fully available in the destination shard on completion of chunk migration. When clients receive the chunk read-only
event, they can either repeat connection attempts until the chunk migration is completed, or access the read-only chunk in the source chunk. In the latter case, an attempt to write to the chunk will result in a run-time error.
57.5.3 Removing a Shard From the Pool
It may become necessary to remove a shard from the sharded database environment, either temporarily or permanently, without losing any data that resides on that shard.
For example, removing a shard might become necessary if a sharded environment is scaled down after a busy holiday, or to replace a server or infrastructure within the data center. Prior to decommissioning the shard, you must move all of the chunks from the shard to other shards that will remain online. As you move them, try to maintain a balance of data and activity across all of the shards.
If the shard is only temporarily removed, keep track of the chunks moved to each shard so that they can be easily identified and moved back once the maintenance is complete.
See Also:
Oracle Database Global Data Services Concepts and Administration Guide for information about using the GDSCTL REMOVE SHARD
command
57.5.4 Adding Standby Shards
You can add Data Guard standby shards to an Oracle Sharding environment; however there are some limitations.
When using Data Guard as the replication method for a sharded database, Oracle Sharding supports only the addition of a primary or physical standby shard; other types of Data Guard standby databases are not supported when adding a new standby to the sharded database. However, a shard that is already part of the sharded database can be converted from a physical standby to a snapshot standby. When converting a physical standby to a snapshot standby, the following steps should be followed:
If the database is converted back to a physical standby, the global services can be enabled and started again, and the shard becomes an active member of the sharded database.
57.5.5 Managing Shards with Oracle Enterprise Manager Cloud Control
You can manage database shards using Oracle Enterprise Manager Cloud Control
To manage shards using Cloud Control, they must first be discovered. Because each database shard is a database itself, you can use standard Cloud Control database discovery procedures.
The following topics describe shard management using Oracle Enterprise Manager Cloud Control:
- Validating a Shard
Validate a shard prior to adding it to your Oracle Sharding deployment. - Adding Primary Shards
Use Oracle Enterprise Manager Cloud Control to add a primary shards to your Oracle Sharding deployment. - Adding Standby Shards
Use Oracle Enterprise Manager Cloud Control to add a standby shards to your Oracle Sharding deployment. - Deploying Shards
Use Oracle Enterprise Manager Cloud Control to deploy shards that have been added to your Oracle Sharding environment.
57.5.5.1 Validating a Shard
Validate a shard prior to adding it to your Oracle Sharding deployment.
You can use Oracle Enterprise Manager Cloud Control to validate shards before adding them to your Oracle Sharding deployment. You can also validate a shard after deployment to confirm that the settings are still valid later in the shard lifecycle. For example, after a software upgrade you can validate existing shards to confirm correctness of their parameters and configuration.
To validate shards with Cloud Control, they should be existing targets that are being monitored by Cloud Control.
- From a shardgroup management page, open the Shardgroup menu, located in the top left corner of the shardgroup target page, and choose Manage Shards.
- If prompted, enter the shard catalog credentials, select the shard director to manage under Shard Director Credentials, select the shard director host credentials, and log in.
- Select a shard from the list and click Validate.
- Click OK to confirm you want to validate the shard.
- Click the link in the Information box at the top of the page to view the provisioning status of the shard.
When the shard validation script runs successfully check for errors reported in the output.
57.5.5.2 Adding Primary Shards
Use Oracle Enterprise Manager Cloud Control to add a primary shards to your Oracle Sharding deployment.
Primary shards should be existing targets that are being monitored by Cloud Control.
It is highly recommended that you validate a shard before adding it to your Oracle Sharding environment. You can either use Cloud Control to validate the shard (see Validating a Shard), or run the DBMS_GSM_FIX.validateShard procedure against the shard using SQL*Plus (see Validating a Shard).
If you did not select Deploy All Shards in the sharded database in the procedure above, deploy the shard in your Oracle Sharding deployment using the Deploying Shards task.
57.5.5.3 Adding Standby Shards
Use Oracle Enterprise Manager Cloud Control to add a standby shards to your Oracle Sharding deployment.
Standby shards should be existing targets that are being monitored by Cloud Control.
It is highly recommended that you validate a shard before adding it to your Oracle Sharding environment. You can either use Cloud Control to validate the shard (see Validating a Shard), or run the DBMS_GSM_FIX.validateShard procedure against the shard using SQL*Plus (see Validating a Shard).
If you did not select Deploy All Shards in the sharded database in the procedure above, deploy the shard in your Oracle Sharding deployment using the Deploying Shards task.
57.5.6 Managing Shards with GDSCTL
You can manage shards in your Oracle Sharding deployment using the GDSCTL command-line utility.
The following topics describe shard management using GDSCTL:
- Validating a Shard
Before adding a newly created shard to a sharding configuration, you must validate that the shard has been configured correctly for the sharding environment. - Adding Shards to a System-Managed SDB
Adding shards to a system-managed SDB elastically scales the SDB. In a system-managed SDB chunks are automatically rebalanced after the new shards are added.
57.5.6.1 Validating a Shard
Before adding a newly created shard to a sharding configuration, you must validate that the shard has been configured correctly for the sharding environment.
Before you run ADD SHARD
, run the validateShard
procedure against the database that will be added as a shard. The validateShard
procedure verifies that the target database has the initialization parameters and characteristics needed to act successfully as a shard.
The validateShard
procedure analyzes the target database and reports any issues that need to be addressed prior to running GDSCTL ADD SHARD
on that database. The validateShard
procedure does not make any changes to the database or its parameters; it only reports information and possible issues.
The validateShard
procedure can also be run after the deployment of a shard to confirm that the settings are still valid later in the shard lifecycle. For example, after a software upgrade or after shard deployment, validateShard
can be run on existing shards to confirm correctness of their parameters and configuration.
Run validateShard
as follows:
sqlplus / as sysdba
SQL> set serveroutput on
SQL> execute dbms_gsm_fix.validateShard
The following is an example of the output.
INFO: Data Guard shard validation requested.
INFO: Database role is PRIMARY.
INFO: Database name is DEN27B.
INFO: Database unique name is den27b.
INFO: Database ID is 718463507.
INFO: Database open mode is READ WRITE.
INFO: Database in archivelog mode.
INFO: Flashback is on.
INFO: Force logging is on.
INFO: Database platform is Linux x86 64-bit.
INFO: Database character set is WE8DEC. This value must match the character set of the catalog database.
INFO: 'compatible' initialization parameter validated successfully.
INFO: Database is not a multitenant container database.
INFO: Database is using a server parameter file (spfile).
INFO: db_create_file_dest set to: '<ORACLE_BASE>/oracle/dbs2'
INFO: db_recovery_file_dest set to: '<ORACLE_BASE>/oracle/dbs2'
INFO: db_files=1000. Must be greater than the number of chunks and/or tablespaces to be created in the shard.
INFO: dg_broker_start set to TRUE.
INFO: remote_login_passwordfile set to EXCLUSIVE.
INFO: db_file_name_convert set to: '/dbs/dt, /dbs/bt, dbs2/DEN27D/, dbs2/DEN27B/'
INFO: GSMUSER account validated successfully.
INFO: DATA_PUMP_DIR is '<ORACLE_BASE>//oracle/dbs2'.
Any lines tagged with INFO
are informational in nature and confirm correct settings. Lines tagged with WARNING
may or may not be issues depending on your configuration. For example, issues related to Data Guard parameters are reported, but if your configuration will only include primary databases, then any Data Guard issues can be ignored. Finally, any output with the ERROR
tag must be corrected for the shard to deploy and operate correctly in a sharding configuration.
57.5.6.2 Adding Shards to a System-Managed SDB
Adding shards to a system-managed SDB elastically scales the SDB. In a system-managed SDB chunks are automatically rebalanced after the new shards are added.
To prepare a new shard host, do all of the setup procedures as you did for the initial sharded database environment including:
-
Registering remote scheduler agents as described in Setting Up the Oracle Sharding Management and Routing Tier
See Also:
Oracle Database Global Data Services Concepts and Administration Guide for information about GDSCTL command usage
57.6 Chunk Management
You can manage chunks in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control and GDSCTL.
The following topics describe chunk management concepts and tasks:
- About Moving Chunks
Sometimes it becomes necessary to move a chunk from one shard to another. To maintain scalability of the sharded environment, it is important to attempt to maintain an equal distribution of the load and activity across all shards. - Moving Chunks
You can move chunks from one shard to another in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control. - About Splitting Chunks
Splitting a chunk in a sharded database is required when chunks become too big, or only part of a chunk must be migrated to another shard. - Splitting Chunks
You can split chunks in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
57.6.1 About Moving Chunks
Sometimes it becomes necessary to move a chunk from one shard to another. To maintain scalability of the sharded environment, it is important to attempt to maintain an equal distribution of the load and activity across all shards.
As the environment matures in a composite SDB, some shards may become more active and have more data than other shards. In order to keep a balance within the environment you must move chunks from more active servers to less active servers. There are other reasons for moving chunks:
-
When a shard becomes more active than other shards, you can move a chunk to a less active shard to help redistribute the load evenly across the environment.
-
When using range, list, or composite sharding, and you are adding a shard to a shardgroup.
-
When using range, list, or composite sharding, and you a removing a shard from a shardgroup.
-
After splitting a chunk it is often advisable to move one of the resulting chunks to a new shard.
When moving shards to maintain scalability, the ideal targets of the chunks are shards that are less active, or have a smaller portion of data. Oracle Enterprise Manager and AWR reports can help you identify the distribution of activity across the shards, and help identify shards that are good candidates for chunk movement.
Note:
Any time a chunk is moved from one shard to another, you should make a full backup of the databases involved in the operation (both the source of the chunk move, and the target of the chunk move.)
See Also:
Oracle Database Global Data Services Concepts and Administration Guide for information about using the GDSCTL MOVE CHUNK
command
57.6.2 Moving Chunks
You can move chunks from one shard to another in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
57.6.3 About Splitting Chunks
Splitting a chunk in a sharded database is required when chunks become too big, or only part of a chunk must be migrated to another shard.
Oracle Sharding supports the online split of a chunk. Theoretically it is possible to have a single chunk for each shard and split it every time data migration is required. However, even though a chunk split does not affect data availability, the split is a time-consuming and CPU-intensive operation because it scans all of the rows of the partition being split, and then inserts them one by one into the new partitions. For composite sharding, it is time consuming and may require downtime to redefine new values for the shard key or super shard key.
Therefore, it is recommended that you pre-create multiple chunks on each shard and split them either when the number of chunks is not big enough for balanced redistribution of data during re-sharding, or a particular chunk has become a hot spot.
Even with system-managed sharding, a single chunk may grow larger than other chunks or may become more active. In this case, splitting that chunk and allowing automatic resharding to move one of the resulting chunks to another shard maintains a more equal balanced distribution of data and activity across the environment.
See Also:
Oracle Database Global Data Services Concepts and Administration Guide for information about using the GDSCTL SPLIT CHUNK
command
57.7 Shard Director Management
You can add, edit, and remove shard directors in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control.
The following topics describe shard director management tasks:
- Creating a Shard Director
Use Oracle Enterprise Manager Cloud Control to create and add a shard director to your Oracle Sharding deployment. - Editing a Shard Director Configuration
Use Oracle Enterprise Manager Cloud Control to edit a shard director configuration in your Oracle Sharding deployment. - Removing a Shard Director
Use Oracle Enterprise Manager Cloud Control to remove shard directors from your Oracle Sharding deployment.
57.7.1 Creating a Shard Director
Use Oracle Enterprise Manager Cloud Control to create and add a shard director to your Oracle Sharding deployment.
57.7.2 Editing a Shard Director Configuration
Use Oracle Enterprise Manager Cloud Control to edit a shard director configuration in your Oracle Sharding deployment.
57.7.3 Removing a Shard Director
Use Oracle Enterprise Manager Cloud Control to remove shard directors from your Oracle Sharding deployment.
If the shard director you want to remove is the administrative shard director, as indicated by a check mark in that column of the Shard Directors list, you must choose another shard director to be the administrative shard director before removing it.
- Open the Sharded Database menu, located in the top left corner of the Sharded Database target page, and choose Shard Directors.
- If prompted, enter the shard catalog credentials, select the shard director to manage under Shard Director Credentials, select the shard director host credentials, and log in.
- Select a shard director from the list and click Delete.
- Click the link in the Information box at the top of the page to view the provisioning status of the shard director removal.
57.8 Region Management
You can add, edit, and remove regions in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control.
The following topics describe region management tasks:
- Creating a Region
Create sharded database regions in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control. - Editing a Region Configuration
Edit sharded database region configurations in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control. - Removing a Region
Remove sharded database regions in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
57.8.1 Creating a Region
Create sharded database regions in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
- Open the Sharded Database menu, located in the top left corner of the Sharded Database target page, and choose Regions.
- If prompted, enter the shard catalog credentials, select the shard director to manage under Shard Director Credentials, select the shard director host credentials, and log in.
- Click Create.
- Enter a unique name for the region in the Create Region dialog.
- Optionally, select a buddy region from among the existing regions.
- Click OK.
- Click the link in the Information box at the top of the page to view the provisioning status of the region.
57.8.2 Editing a Region Configuration
Edit sharded database region configurations in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
- Open the Sharded Database menu, located in the top left corner of the Sharded Database target page, and choose Regions.
- If prompted, enter the shard catalog credentials, select the shard director under Shard Director Credentials, select the shard director host credentials, and log in.
- Select a region from the list and click Edit.
- Select or remove a buddy region, and click OK.
- Click the link in the Information box at the top of the page to view the provisioning status of the region configuration changes.
When the region configuration is successfully updated the changes appear in the Regions list. You might need to refresh the page to see the updates.
57.8.3 Removing a Region
Remove sharded database regions in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
- Open the Sharded Database menu, located in the top left corner of the Sharded Database target page, and choose Regions.
- If prompted, enter the shard catalog credentials, select the shard director under Shard Director Credentials, select the shard director host credentials, and log in.
- Select a region from the list and click Delete.
- Click the link in the Information box at the top of the page to view the provisioning status of the region removal.
When the region configuration is successfully removed the changes appear in the Regions list. You might need to refresh the page to see the updates.
57.9 Shardspace Management
You can add, edit, and remove shardspaces in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control.
The following topics describe shardspace management tasks:
- Creating a Shardspace
Create shardspaces in your composite Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
57.9.1 Creating a Shardspace
Create shardspaces in your composite Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
57.10 Shardgroup Management
You can add, edit, and remove shardgroups in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control.
The following topics describe shardgroup management tasks:
- Creating a Shardgroup
Create shardgroups in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.
57.11 Services Management
You can manage services in your Oracle Sharding deployment with Oracle Enterprise Manager Cloud Control.
To manage Oracle Sharding services, open the Sharded Database menu, located in the top left corner of the Sharded Database target page, and choose Services. On the Services page, using the controls at the top of the list of services, you can start, stop, enable, disable, create, edit, and delete services.
Selecting a service opens a service details list which displays the hosts and shards on which the service is running, and the status, state, and Data Guard role of each of those instances. Selecting a shard in this list allows you to enable, disable, start, and stop the service on the individual shards.
The following topics describe services management tasks:
- Creating a Service
Create services in your Oracle Sharding deployment using Oracle Enterprise Manager Cloud Control.