3 Administering Global Data Services Configurations
The GDSCTL utility is used to create, manage and monitor a Global Data Services configuration and all of its components. This utility is very similar to the SRVCTL utility used to manage an Oracle Real Application Cluster (Oracle RAC). The following topics explain how to administer your GDS configurations.
Topics:
3.1 Overview of Global Data Services Administration
Global Data Services is managed by the Global Data Services administrator whose responsibilities include the following tasks:
-
Installing and upgrading the global service manager software
-
Creation and maintenance of the Global Data Services catalog
-
Starting, stopping, and configuring global service managers
-
Creation and administration of Global Data Services regions and pools
-
Management of global services
-
Monitoring of the Global Data Services framework components
Each Global Data Services configuration requires at least one Global Data Services administrator. A small configuration can be administered by a single person who performs all the administrative duties. For a large configuration with many regions and pools it may be necessary to have a group of Global Data Services administrators who share responsibilities. All Global Data Services administrators have privileges to perform all the listed administrative tasks for a given Global Data Services configuration.
An operating system account should exist for the Global Data Services administrator on all computers where global service managers are expected to run. The account user should have privileges to install and run global service manager software. Only Global Data Services administrators should be granted these privileges.
A Global Data Services administrator must also be added as a user to the Global Data Services catalog database and granted the GSMADMIN_ROLE role. The database account for a Global Data Services administrator should be created by a database administrator of the catalog database. The Global Data Services administrator might create this account by himself if he happens to have local database administrator privileges on this database.
If a Global Data Services configuration contains multiple pools, then in addition to Global Data Services administrators who manage the entire configuration, each pool can have one or more Global Data Services pool administrators. Responsibilities of a pool administrator are limited to the administration of a particular pool and include the following tasks:
-
Adding and removing databases in the pool
-
Management of global services in the pool
To perform these tasks a Global Data Services pool administrator must be a user of the Global Data Services catalog database with the appropriate privileges. Creation of the database user for a pool administrator and granting of the privileges is performed automatically when a Global Data Services pool is created with the -USER option. A pool administrator can also be added to a pool after its creation using gdsctl modify gdspool command. A Global Data Services administrator always has privileges to administer any pool in the database configuration.
All administrative operations should be performed using the appropriate GDSCTL commands. Execution of the most GDSCTL commands requires access to the Global Data Services catalog. For such commands, credentials for the catalog database must be specified using the appropriate command options.
Many administrative operations, such as adding a database to a Global Data Services pool, or enabling a global service, require making changes not only to the Global Data Services catalog, but also to databases in the Global Data Services configuration. The generic workflow for such commands is as follows:
-
GDSCTL connects to the catalog database with credentials provided by the administrator and makes appropriate changes to the catalog.
-
The catalog database notifies all global service managers in the Global Data Services configuration about the changes. The notification is sent using an Oracle Net Services connection that each global service manager maintains with the catalog database.
-
After receiving the notification one of the global service managers connects to the configuration databases that need to be configured and makes the appropriate changes.
To support this workflow a global service manager should be able to connect to the catalog and configuration databases. The connection to the catalog database is established using GSMCATUSER account, which is created by default on any Oracle 12c database during database installation. The account must be unlocked by the database administrator of the catalog database and its password given to the Global Data Services administrator. Whenever a new global service manager is added to the GDS configuration, the Global Data Services administrator has to specify the password for the GSMCATUSER account. The password is then encrypted and stored in the global service manager wallet for future use by the global service manager.
The global service manager connects to the pool databases using the GSMUSER account, which also exists by default on any Oracle 12c database. The account is locked after the database installation. It should be unlocked by the local database administrator before the database can be added to a Global Data Services pool. The password for the GSMUSER account is given to the pool or Global Data Services administrator who adds the database to a Global Data Services pool and must be specified in the gdsctl add database command. The password is stored in the Global Data Services catalog for future use by all global service managers.
The GSMUSR passwords are stored the GDS catalog in an encrypted form using the PKCS 1 encryption/decryption schema. You can encrypt GSMUSR passwords stored in the GDS catalog with a newly generated keys by executing the modify catalog command. For example:
GDSCTL> modify catalog -newkeys
GSMCATUSER and GSMUSER accounts are shared by all global service managers in the Global Data Services framework and used for all management operations performed by global service managers, including automatic operations such as service failover. Human users should never connect to databases using these accounts.
3.2 Managing Database Pools
This section describes the administration tasks associated with managing database pools in the global data services framework. It contains the following topics:
3.2.1 Adding Oracle Data Guard Broker Managed Databases to a Database Pool
When you include an Oracle Data Guard broker configuration in a Global Data Services configuration, you manage the broker configuration as one unit. Only an entire Oracle Data Guard broker configuration can be added to (or deleted from) a database pool. A configuration cannot span multiple pools. An attempt to add or remove an individual database to or from a pool that belongs to a broker configuration results in an error.
The only way to add a database to the pool is to add the database to the broker configuration (using the DGMGRL utility). Adding a database to the broker configuration causes its automatic addition to the database pool to which this configuration belongs. Removing a database from a broker configuration causes its removal from the pool that contains the configuration. This is the only way to remove a database from a pool that contains a broker configuration.
Also, note the following limitations:
-
The set of databases in a database pool can be either:
-
The set of databases that belong to a single broker configuration
-
A set of databases that belong to no broker configuration
You can add a broker configuration only to an empty database pool and, if a pool already contains a broker configuration, then, to add a database to a database pool, you must add the database to the broker configuration contained in the database pool.
-
-
Role-based global services are supported only for database pools that contain a broker configuration.
See Also:
Oracle Data Guard Broker for more information about the DGMGRL utility
3.3 Managing Global Services
This section describes the administration tasks associated with global services. It contains the following topics:
Topics:
3.3.1 Creating a Global Service
A global service is created by execution of the add service command. This command associates the global service with a Global Data Services pool and stores attributes of the service in the Global Data Services catalog. If databases are specified using the —preferred or —available options, the service is created on those specified databases. If the —preferred_all option is used, the service is created on all databases in the Global Data Services pool.
A service that already exists in a Global Data Services pool is also automatically created on a database in the following cases:
-
The service is modified to add a database that is part of the pool.
-
The service has the
—preferred_allattribute and a new database is added to the pool.
See Also:
3.3.2 Starting a Global Service
A global service is automatically enabled immediately after it has been created. The term enabled means that the service can be started on a database if the database is eligible for running the service, namely, when the following conditions are met:
-
The database is open and registered with a global service manager.
-
The service has not been disabled on that database.
-
The database role matches the role attribute of the service.
-
The replication lag on the database does not exceed the maximum value specified for the service.
-
The service has not reached its cardinality defined by the number of preferred databases.
-
No other database in the pool is a better candidate for starting the service, for example, the service can be started on an available database only if there is no eligible preferred database.
A newly created global service never gets started automatically until the start service command is executed by the user. This gives the pool administrator control over the initial service startup which may be important in the case when multiple services are being added to the pool and a certain sequence of service startups is required.
A service with the automatic management policy (the default option) must be initially started by executing the start service command without the -database option. This command not only starts the service on all eligible databases in the pool, but also enables the automatic service startup in the following cases:
-
After the service is automatically created on a database that is eligible to run it. (The two cases of automatic service creation are listed in the previous section.)
-
A database that was down gets restarted and is eligible for the service.
-
A database becomes eligible to run the service. This can happen, for example, because the replication lag on a database has decreased to an acceptable value, or the service cardinality has been increased by the user.
The start service command with -database option can be used to start a service with the automatic management policy on particular databases if the service was shut down there by the stop service command described in Stopping a Global Service.
A service with the manual policy must be started manually on each individual database, including when a database gets restarted or becomes eligible to run the service. When executed against a service with the manual policy, the start service command without the -database option starts the service on all eligible databases that are currently present in the pool. If used with the -database option, the command starts the service only on the specified databases, if they are eligible to run it.
Note:
The cases of automatic service startup listed in this section only describe what happens when the start service command is executed against a service with the automatic management policy. They do not include cases when a service is started automatically on a database because of a failover from another database. Service failover is not associated with the start service command, and its behavior is the same for services with automatic and manual management policy.
See Also:
3.3.3 Stopping a Global Service
A global service running on databases in a Global Data Services pool can be shut down by the stop service command. If the stop service command is executed with the -database option, then the service is stopped on the specified databases; otherwise it is stopped on all databases in the pool.
Note:
A stopped service with the automatic management policy is restarted if the database where it was running gets restarted and is eligible to run the service. Also, stopping a service with the automatic management policy on all databases in a Global Data Services pool does not prevent the automatic service startup on a new database when the service is created there. To completely disable the automatic startup of a service, its management policy should be changed to manual.
When the service is stopped by the user, the Global Data Services framework considers that database to be temporarily unavailable for this service. Stopping a global service does not cause a service failover event; the service cardinality is temporarily decreased and the global service manager does not attempt to start the service on another database in the pool.
However, a database with a stopped service is still considered a failover target for this service; when the service fails on another database, it can be started on this database if it is eligible to run the service. After the service failover to a database, the service on that database is no longer considered to be stopped by the user.
A stopped service can be manually restarted by executing the start service command.
See Also:
3.3.4 Disabling a Global Service
A global service can be disabled on a database or a set of databases by executing the disable service command. A disabled service cannot be started until it is reenabled. This includes the service failover from another database; a database with the disabled service is never considered a failover target.
A service has to be stopped to be disabled. An error is returned if disable service is executed against a database where the service is running.
See Also:
3.3.5 Enabling a Global Service
A disabled global service can be reenabled on a database by executing enable service command. If the service management policy is AUTOMATIC and the database is eligible for running the service, it is started automatically after being enabled. A service with the MANUAL management policy must be started manually. A database can become a failover target after a service is enabled there.
See Also:
3.3.6 Modifying Global Service Attributes
The modify service command is used to modify global service attributes. In addition to specifying service properties (such as role, maximum lag, load balancing method, and so on) service attributes define on which databases the service should run. Therefore modify service can be used to add a database to a service, remove it from a service, or move a service from one database to another. As the result of the command execution, a service may be created, deleted, started, or stopped on one or more databases in a Global Data Services pool.
Most global service attributes are specified at the service creation time in the add service command and only need to be modified when some changes have to be made. However, a few service attributes related to Oracle RAC databases, must be set by executing the modify service command right after the add service command has been executed. These attributes include the name of the server pool, instance cardinality (UNIFORM/) and some other parameters that are specific to particular Oracle RAC databases. Such attributes cannot be set by the add service command because this command is only used to specify attributes that have the same values for all databases in a Global Data Services pool.
See Also: