Before you install any software, review these hardware, network, operating system, and other software requirements for Linux.

• Each and every GDS pool database must be able to reach (in both directions) each and every global service manager’s Listener and ONS ports. The global service manager Listener ports and the ONS ports must also be opened to the Application/Client tier, all the GDS pool databases, the GDS catalog and all other global service managers.

• The TNS Listener port (Default: 1521) of each GDS pool database must be opened (in both directions) to global service managers and the GDS catalog.

• If GDSCTL is run from a separate machine, you also must have a port opened (in both directions) from that machine directly to each GDS pool database that is added.

Global Data Services components require:

• At least 256MB of total physical memory

• At least 20MB of available physical memory

• At least 6 GB of total swap space

• At least 1.5 GB of free disk space

• Certified architecture, for example x86_64

• Linux system kernel version is at least "2.6.18"

• Package make-3.81 is available on the system

• Package binutils-2.17.50.0.6 is available on the system

• Package gcc-4.1.2 (x86_64) is available on the system

• Package libaio-0.3.106 (x86_64) is available on the system

• Package libaio-devel-0.3.106 (x86_64) is available on the system

• Package libstdc++-4.1.2 (x86_64) is available on the system

• Package sysstat-7.0.2 is available on the system

• Package compat-libstdc++-33-3.2.3 (x86_64) is available on the system

• Package libgcc-4.1.2 (x86_64) is available on the system

• Package libstdc++-devel-4.1.2 (x86_64) is available on the system

• Package glibc-devel-2.5 (x86_64) is available on the system

• Package gcc-c++-4.1.2 (x86_64) is available on the system

• Package glibc-2.5-58 (x86_64) is available on the system

• Package ksh-... is available on the system

The global service manager is the central component of the Global Data Services framework, and you must install the global service manager using separate media. No other Oracle software is required to install and run the global service manager.

You can install the global service manager on a system where you have other Oracle products installed, but you must install the global service manager in a separate Oracle home directory. You can install more than one global service manager on a single system, but each global service manager must have a separate Oracle home directory. For performance reasons, depending on the number of databases in your Global Data Services configuration, you may want to deploy the global service manager on a dedicated host.

You must install at least one global service manager for each Global Data Services region. Global service managers can be hosted on physical or virtual environments. For high availability, Oracle recommends installing multiple (typically 3) global service managers in each region running on separate hosts.

The Global Data Services administrator installs the global service manager. The Global Data Services administrator's responsibilities include:

• Administering global service managers

• Administering the Global Data Services catalog

• Administering regions and database pools

1. Start Oracle Universal Installer from the root directory of the software media and follow the prompts.

   When the installation completes, the global service manager home directory contains binaries required to run the global service manager and the Global Service Manager Control utility (GDSCTL).

2. Set the ORACLE_HOME environment variable to the directory you specified during installation.
3. Add the $ORACLE_HOME/bin directory created for the global service manager to the PATH environment variable.
4. Set the TNS_ADMIN environment variable set to $ORACLE_HOME/network/admin.

There are four components that comprise the distributed Global Data Services infrastructure, and each component may reside in a separate installation and may be upgraded independently using the usual upgrade procedure; however, there are certain rules about component versioning that should be followed. The components and rules are as follows:

• Catalog database: The catalog database is the central repository for the GDS metadata; it is a standard Oracle Database installation. The version of the catalog database must always be greater than or equal to the version of any GDSCTL session that connects to it, and exactly equal to the version of any global service manager server that connects to it, with one exception: to ease migration, the catalog may temporarily have a version greater than some global service manager servers that are connected to it, until any change is made to the catalog, at which time any connected global service manager that is not at the same version will be disconnected, and any stopped global service manager that is not at the same version will not be allowed to connect.

  Note:

  GDSCTL sessions running release 12.1.0.1 cannot make changes to a later versioned catalog; when running commands that will update the catalog, the GDSCTL client should be at a minimum version of 12.1.0.2.

• GDSCTL client: This component is run in an ad-hoc manner from a terminal session on any system that contains a global service manager installation. The version of the GDSCTL client is the version of the global service manager installation that it runs from.

  Note:

  When connecting a 12.1.0.1 GDSCTL client to a later versioned catalog only a limited set of commands are allowed, and any command that may cause catalog changes will result in a compatibility error. Commands that update the catalog metadata in a catalog at version 12.1.0.2 or later should be executed from a GDSCTL client running at least release 12.1.0.2.

• Global service manager server: The version of the global service manager server is the version of the global service manager installation from which the server runs. A global service manager server cannot connect to any catalog database that is at a lower version than itself. A global service manager server cannot connect to any catalog database that is at a higher version than itself in which changes have already been made to the catalog at that higher version. A global service manager can connect to a pool database running any version of Oracle Database 12c or later.

• Pool database: A pool database is any database added to a GDS pool which runs a global service. A pool database may be at any version of Oracle 12c or later, including versions later than the catalog version. You may upgrade or downgrade pool databases at any time.

Given these rules, it is possible to perform a rolling upgrade of the distributed GDS infrastructure with zero service downtime.

1. Upgrade the catalog database. For best results this should be done using a rolling database upgrade; however, global services will remain available during the upgrade if the catalog is unavailable, although service failover will not occur.

   Note:

   When upgrading Oracle Database 12c Release 1 with the 12.1.0.2 patch release, you must execute the following command after upgrading the catalog database:

   modify catalog -newkeys

   This command generates encryption keys and encrypt existing GSMUSR passwords stored in the GDS catalog.

2. Upgrade global service manager installations that are used to run GDSCTL clients, which do not also run a global service manager server (if any).

   Note:

   Global service manager upgrades should be done in-place; however, an in-place upgrade will cause erroneous error messages unless permissions on the following files for the following platforms are updated to 755:

   On Linux/Solaris64/Solaris Sparc64:

   $ORACLE_HOME/QOpatch/qopiprep.bat

   $ORACLE_HOME/jdk/bin/jcontrol

   $ORACLE_HOME/jdk/jre/bin/jcontrol

   On AIX:

   $ORACLE_HOME/QOpatch/qopiprep.bat

   $ORACLE_HOME/jdk/jre/bin/classic/libjvm.a

   $ORACLE_HOME/jdk/bin/policytool

   On HPI:

   $ORACLE_HOME/jdk/jre/lib/IA64N/server/Xusage.txt

   $ORACLE_HOME/jdk/jre/bin/jcontrol

   $ORACLE_HOME/QOpatch/qopiprep.bat

   On Windows, no error messages are expected.

3. Stop, upgrade, and restart all global service manager servers one-at-a-time. In order to ensure zero downtime, at least one global service manager server should always be running. Global service manager servers at an earlier version than the catalog will continue to operate fully until catalog changes are made.
4. Upgrade pool databases in any order, either before or after the global service manager and catalog database upgrades, at the discretion of the pool database administrator.

Every Global Data Services configuration must have a Global Data Services catalog. The Global Data Services catalog can reside on the same host as a GDS configuration database, but Oracle does not recommend this scenario for large configurations. Oracle recommends that you use Oracle high availability features such as Oracle Real Application Clusters (Oracle RAC) and Oracle Data Guard to protect the Global Data Services catalog against outages.

GDSCTL> create gdscatalog -database serv1:1521:catdb.example.com 
    -user gsm_admin

1. Alter the GSMCATUSER account.

   Every global service manager in a Global Data Services configuration maintains a direct Oracle Net Services connection to the catalog database under the GSMCATUSER account, which is created by default during Oracle Database 12c installation. The database administrator (DBA) of the catalog database must unlock the account and give the account password to the Global Data Services administrator.

   ALTER USER gsmcatuser ACCOUNT UNLOCK;
   ALTER USER gsmcatuser IDENTIFIED BY password;
   

2. Run the following command on the host where you want the global service manager to run:

   GDSCTL> add gsm -gsm gsm_name -listener listener_port -catalog catalogdb_name
   

   For example:

   GDSCTL> add gsm -gsm east_gsm1 -listener 1523 -catalog
       serv1:1521:catdb.example.com
   

   In the preceding example, serv1:1521:catdb.example.com is the connect identifier of the catalog database. The Global Data Services administrator is prompted for the GSMCATUSER password during the execution of the command.

   See Also:

   add gsm for complete usage information

3. After you add the global service manager to the Global Data Services framework, start the global service manager, as follows:

   GDSCTL> start gsm -gsm gsm_name
   

   During startup, the global service manager creates or modifies the ONS.CONFIG file and populates the file with configuration data from the Oracle Notification Service server that belongs to the global service manager.

   By default, the file is created in the $ORACLE_HOME/opmn/conf directory. The location can be changed to $ORACLE_CONFIG_HOME/opmn/conf if the environment variable ORACLE_CONFIG_HOME is set.

   Note:

   The ONS.CONFIG file cannot be shared, and there must be a unique ONS.CONFIG file for each global service manager installation.

Many GDSCTL commands require a connection to the Global Data Services catalog. You can connect to the Global Data Services catalog using one of the following two methods:

GDSCTL> connect [user_name]@connect_identifier

GDSCTL> connect gsm_admin@catalog
Enter password: ******
Catalog connection is established
GDSCTL>

catalog = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xyz)(PORT=1523))
    (ADDRESS=(PROTOCOL=tcp)(HOST=abc)(PORT=1523))
)

$ gdsctl add gdspool -gdspool hr -catalog  mygdscatlog

username:Robert
password:

Large database clouds can require multiple Global Data Services pools that are managed by different administrators.

For example:

GDSCTL> add gdspool -dbpool hr -users rjones

The preceding example adds a Global Data Services pool called hr, and adds the user rjones, who is assigned the privileges to administer the hr pool. The privileges enable the pool administrator to add databases to the pool and manage global services on the databases in the pool.

A Global Data Services pool must have a unique name within its GDS configuration. If you do not specify a name for the pool when you create it, then the name defaults to oradbpool. The pool name can be up to 30 bytes long and can be any valid identifier (an alphabetical character followed by zero or more alphanumeric ASCII characters or the underscore (_)).

For example:

GDSCTL> add region –region west,east

The preceding example adds two regions, east and west, to the Global Data Services framework.

A Global Data Services region should have a name that is unique within the corresponding Global Data Services configuration. If no name is specified at the first region creation time, the default name, oraregion, is given to the region. The region name can be up to 30 characters long and can be any valid identifier - an alphabetical character followed by zero or more alphanumeric ASCII characters or '_'.

ALTER USER gsmuser ACCOUNT UNLOCK;
ALTER USER gsmuser IDENTIFIED BY password;

1. Connect to the Global Data Services catalog using the Global Data Services pool or Global Data Services administrator credentials, for example:

   GDSCTL>connect rjones@catalog
   

2. Run the gdsctl add database command:

   GDSCTL>add database -connect edc007:1521/db14.east.example.com -region east
    -gdspool hr

   In this example edc007:1521/db14.east.example.com is the connect identifier of the database, and then you are prompted for the GSMUSER account password on this database.

The gdsctl add service command is used to create a service on the Global Data Services pool databases. A simple example of the command is as follows:

GDSCTL> add service -gdspool hr -service emp_report1 -preferred_all

In this example emp_report1 is the service name and the -preferred_all option means that the service should normally run on all of the databases in the pool.

The service name specified in the 'add service' command can be domain qualified (for example, sales.example.com) or not (for example, sales). If the specified name is not domain qualified, the service is created with the default domain name "<GDS_pool_name>.<GDS_configuration_name>", however the shorter non-domain qualified name can be used with subsequent GDSCTL commands to manage the service. If the specified name is domain qualified, the full domain qualified service name must be used in all subsequent GDSCTL commands used to manage the service.

For Oracle RAC-enabled pool databases, after the service has been added, run GDSCTL modify service to specify which Oracle RAC instance a given global service should run on, as shown in the following example.

GDSCTL> modify service -service emp_report1 -gdspool hr - database db14
 -modify_instances -preferred db14_n1, db14_n2

A global service name must be unique within a GDS pool and when qualified by domain, must also be unique within a GDS configuration. A global service cannot be created at a database if a local or global service with the same name already exists at that database.

A global service name can contain alphanumeric characters, "_' and '.'. The first character must be alphanumeric. The maximum length of a global service name is 64 characters. The maximum length of a domain qualified global service name is 250 characters.

An Oracle Net connect descriptor used to connect to a global service must contain a domain qualified service name

The gdsctl start service command is used to start an existing service on the Global Data Services pool databases.

GDSCTL>start service -service emp_report1 -gdspool hr

If the -role parameter is specified for the service, the service only starts on the databases in which the role matches the specified value. If the -lag parameter is specified for the service, the service only starts on the databases for which replication lag does not exceed the specified value. Unless -preferred_all is specified for the service, the service only starts on the databases that are listed as preferred for the service.

Database clients connect to database services using an Oracle Net connect string. The connect string used for a global service differs from the connect string used for a local service in the following ways:

• The service name parameter in the connection data section specifies a global service

• Multiple connection endpoints are specified, and these endpoints are global service managers rather than local, remote, or single client access name (SCAN) listeners

• The database client's region may be specified in the connection data section

Consider the following connect string:

 (DESCRIPTION=
  (FAILOVER=on)
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(host=sales-east1)(port=1522))
    (ADDRESS=(host=sales-east2)(port=1522))
    (ADDRESS=(host=sales-east3)(port=1522)))
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(host=sales-west1)(port=1522))
    (ADDRESS=(host=sales-west2)(port=1522))
    (ADDRESS=(host=sales-west3)(port=1522)))
  (CONNECT_DATA=
   (SERVICE_NAME=sales)
   (REGION=east)))

This connect string contains three global service managers (sales-east1, sales-east2, and sales-east3) in the client's local region (east), and three global service managers (sales-west1, sales-west2, and sales-west3) in the client's buddy region (west).

Client-side load balancing is enabled across the global service managers within each region by setting the LOAD_BALANCE parameter to ON in the address list for each region. Connect-time failover between regions is enabled by setting the FAILOVER parameter to ON.

It is a best practice to have three global service managers in each region, for each region to have a buddy region, and for client-side load balancing and connect-time failover to be configured as shown in the example connect string.

The REGION parameter is optional if only global service managers from the local region are specified in the connect string. This is the case when there is only one region in the GDS configuration, or could be the case when there are multiple regions, but it is not feasible to change the connect string of an existing client designed to work with a single database. If the REGION parameter is not specified, the client's region is assumed to be the region of the global service manager used to connect to the global service.

The Oracle Database 12c and later integrated clients use Oracle Notification Services (ONS) to receive the Fast Application Notification (FAN) events that support load balancing and Fast Connection Failover (FCF). The integrated clients automatically subscribe, without user-configuration, to up to 3 of the ONS servers co-located with the global service managers in each of the client's local and buddy regions.

Because the GDS catalog stores metadata for the entire GDS configuration, loss or corruption of the catalog data may require significant efforts to manually recreate it. While unavailability of the GDS catalog does not impact core GDS functionality such as load balancing, service failover, and application notification, no changes can be made to the GDS configuration until the catalog is restored. Therefore it is important to develop a strategy for protecting the GDS catalog.

Even when the GDS catalog is protected by HA technologies such as Oracle RAC and Data Guard, it is highly recommended that you regularly back up the GDS catalog. You can create a logical backup of the catalog by exporting the catalog data to a file. This backup of the GDS catalog can help you in a disaster recovery scenario, and when there is need to undo changes made to the catalog since the last backup was made. You can also use the backup when moving the GDS catalog to a new database.

The catalog configuration will be saved to the specified file on the system where GDSCTL is running. Access to the file should be limited to Global Data Services administrators since it may contain sensitive information such as connection strings for the pool databases.

1. Run the following command in SQL*Plus while connected to the GDS catalog:

   ALTER USER gsmcatuser IDENTIFIED BY ****
   

2. Then in GDSCTL run the following command:

   GDSCTL> modify catalog -oldpwd oldpassword -newpwd newpassword