Written By

Introduction

Prior to 12c we are familiar with the local data services which offers the connectivity to the desired database and managed workload across instances and route the connection to the standby databases and vice versa. From 12c now we can manage the services  more efficiently and we can centralize database services when managing the replication methods such as Data Guard or Golden Gate. This article explains all about it.

 Local data services

Before starting directly with GDS, we will see how we used local data services so far and of course still. For example in case of RAC systems we may have many services or few, as a real world example for PeopleSoft applications called "Nvision" reports which are purely select statements and runs very frequently and many times a day as required. If the job run to fetch the information of entire quarter and many times in business hours and of course there is overhead to the production, To lift this pressure on production we can use Physical standby to run the reports with the Active Data Guard license.  The local data services are supported in any versions or releases.

For example if the user connects to the production/primary database with a service to run nvision reports and then we can divert the connection to establish in physical standby database. That can be done using the triggers like below.

CREATE OR REPLACE TRIGGER PSoftReports AFTER STARTUP ON DATABASE
DECLARE
DBROLE VARCHAR2(40);
BEGIN
SELECT DATABASE_ROLE INTO DBROLE FROM V$DATABASE;
IF DBROLE= 'PRIMARY' THEN
DBMS_SERVICE.START_SERVICE('FINRW');
ELSE
DBMS_SERVICE.START_SERVICE('NvJob');
END IF;
END;
/

Likewise we can also configure when RAC in use

$srvctl add service -database FINDB -service NvJob -role PHYSICAL_STANDBY -failovertype SELECT -failovermode BASIC  -preferred FEDBDR -available FINDB

Local data services can be managed with the limited environment, but when comes huge environment in picture like multiple standby databases and golden gate integrated so on then managing with local data services is too complex.  But when managing local data services you have to create the services of primary on primary and also standby databases, same time need to create services of physical standby role on primary and standby database. Finally you end up with creating services on each site.

Global data services

Global Data services were introduced in 12.1.0.1 and this concept is completely new and designed for the high available and replication environments. To use this feature either Active Data Guard should be licensed or Golden Gate license. GDS greatly provisions dynamic load balancing of the sessions and failovers, Replication lag based routing, Role based global services with the centralized management. GDS works either with RAC or Non-RAC/Stand alone databases and support with Data Guard, Golden gate or any other replication tools.   In case of local data services the features of GDS are considered to be disadvantages such as no automatic load balancing and no centralized workload management. Global data services are applicable if the database is 12c and for the prior to 12c databases only local data services works. The local data services we cannot transform into global data services, we need to create new global service with the information from local data services. The GDS frame work is divided into logical and physical components, in which the logical components are GDS configuration, GDS pools and GDS region and the physical components are considered as GSM , GDS catalog, notification servers and the GDSCTL utility.

GDS designed in a such way where it is comfortable if the environment of High Availability i.e. Policy managed RAC or Data Guard or Integrated with Broker, database cardinality , Replication(standby, golden gate) lag, Distributed transaction processing and also support of pluggable database.

In a nutshell for the distributed environments, Unified GDS framework transparently manages client workload across replicated databases.

GDS word may be confused when used "Globally" but it is not necessary that the databases should be distributed entirely different location, it can be in same zone, location. Another confusion if there are 2 or more data centers involved and confused to use which service to connect whether read/write database or read only database? GDS will work smart with the service name you are using.

As we know GDS is shared infrastructure to manage the configuration and it can capable of managing 300 database instances, 1000 global services, 20 GDS pools and 10 GDS regions and maybe in the future the number is vary in upcoming releases/versions.

GDS Components

To say GDS is a single component but in fact it is framework of various tools, services and objects involved, All of the components are involved either in a single data center or multiple.  We will go through of each component of GDS in short about it.

Global Service Manager  - GSM is the one of the middle layer in the GDS involved architecture, GDS plays key role as HUB in between the database servers and the services used by users. Services whichever used by users will first communicated to GSM(Listens incoming connections) and then GSM coordinate to perform service level load balancing and failover of the services, publishes real time load balancing advisory and monitors all the databases to collect the important information of availability and the service load. GDS is very smart and estimates to which database the connection should be routed and these all statistics are based on the information/metrics collected by GSM. Global services can be one or more but it can communicate with only one GDS configuration and no way it can contact to the other GDS configuration, same time GSM can be only one per the region for example APAC.

GDS Catalog - Probably the question might be why to have catalog database in GDS configuration? and additional overhead?  For example when managing Data Guard broker we have seen the broker configuration file to store all the information of configuration, like wise GDS also needs a database to store all the information + metadata of configuration. There is no necessary to have catalog database within the configuration of GDS but it can be reside outside the configuration, ensure within the optimal distance or same region. When it comes to the catalog database the version should be 12c (minimum 12.1.0.1). The entire GDS configuration is the key role to manage the services and we can consider the high availability solutions to catalog database, such as RAC database or creating Data Guard for catalog database.

GDSCTL  We have seen various tools to manage oracle products such as RMAN, DGMGRL to manage Data Guard, EMCLI to manage enterprise manage.. like wise to manage the global data services the new utility GDSCTL will be used to configure, manage and administer the services. When we connect to GDSCTL it makes connection to GSM, catalog database and all the database which are under part of GDS configuration. Apart from that GDSCTL is not only limited to the command line but this can be managed using GUI with the EM 12.1.0.5 + Plug-in. With this utility many operations can be performed such as adding GSM to the configuration, Starting and stopping the GSM, Modifying the configuration parameters of GSM, obtaining status of the GSM, Adding database to the GDS configuration, Adding service to the GDS pool and validating catalog database.

GDSCTL is another friendly utility, we can get all the syntax and example of each command related to the GDS management. 

GDSCTL>help add gsm
Syntax
- ADD GSM -gsm gsm_name -catalog catalogdb_name [-pwd password] [-region region_name]
[-localons ons_port] [-remoteons ons_port] [-listener listener_port]
[-endpoint gsmendpoint [-remote_endpoint remotendpoint]][-trace_level level] [-wpwd password]
Purpose
Adds a GSM to GDS configuration (by specifying the GDS catalog database)
Usage Notes
If -localons or -remoteons are not specified, the default ONS ports will be used.
If -region is not specified and there is only one region in GDS catalog, then GSM will be added to that GDS region.
Keywords and Parameters
-gsm a GSM name.
-catalog GDS catalog connection string ( TNS alias).
-pwd GSMCATUSER credentials.
-region GDS region GSM belongs to.
-remoteons the remote ons port (default 6234).
-localons the local ons port (default 6123).
-listener the listener port default (1522).
-endpoint GSM endpoint (overrides default endpoint).
-remote_endpoint remote listener endpoint (overrides endpoint).
-trace_level <number | [ERROR, USER, ADMIN, SUPPORT, OFF]>.
-wpwd wallet password.
Examples
GDSCTL> ADD GSM -gsm gsm1 -catalog dbc

GDSCTL>

GDS Region - For example of the big organizations and managing databases in various global regions such as APAC, EMEA(Europe, Middle east), North America and so on and having many number of databases, in this case managing and recognizing GSM, Databases may be challenging. To avoid this each region name we can call it as APAC GSM, EMEA GSM so on, in such a way we can add the list of the databases to a specific region.

GDS Pool - GDS pool is to be considered as the set of the services which are part of the Global data services configuration, like we used the two example services FINRW, NVJOB and the services can be any type either read write or read only and so on.

Global Service - We have already seen local data services but When these services managed by GSM and routes the connection to preferred database(load balancing), failover of services based on the unavailability of the database and so on we can termed as global service and not limited to specific database.

GSM Software -  So far we have seen only the components of the GDS and architecture but in order to configure, administer and monitor we need to have software engine to manage called global service manager, this can be downloaded from the edelivery.oracle.com website and available with the versions of 12.1.0.1 and 12.1.0.2.

-bash-4.1$ cd /home/oracle/softwares/
-bash-4.1$ ls -ltr
pwtotal 554084
-rwxrwxrwx 1 oracle dba 567375160 Feb 22 19:30 V46099-01_GDS12.1.0.2.zip
-bash-4.1$ pwd
/home/oracle/softwares
-bash-4.1$ unzip V46099-01_GDS12.1.0.2.zip
Archive: V46099-01_GDS12.1.0.2.zip
creating: gsm/
creating: gsm/response/
inflating: gsm/response/gsm_install.rsp
inflating: gsm/runInstaller
inflating: gsm/welcome.html
creating: gsm/install/
...
..
.
inflating: gsm/stage/globalvariables/globalvar.xml
creating: gsm/stage/sizes/
extracting: gsm/stage/sizes/oracle.gsm.Complete.sizes.properties
inflating: gsm/stage/sizes/oracle.dslm.12.1.0.2.0.sizes.properties
inflating: gsm/stage/sizes/oracle.dslm12.1.0.2.0Typical.sizes.properties
inflating: gsm/stage/sizes/oracle.dslm12.1.0.2.0Complete.sizes.properties
-bash-4.1$ ls -ltr
total 554088
drwxr-xr-x 5 oracle dba 4096 Jul 7 2014 gsm
-rwxrwxrwx 1 oracle dba 567375160 Feb 22 19:30 V46099-01_GDS12.1.0.2.zip
-bash-4.1$

 

Setup of GSM         

We will cover in detail installation and setup of the GDS in the upcoming articles, but we will see what are the main configuration steps involved to prepare GDS.

  1. Installation of GSM software.
  2. Create gsmadmin user.
  3. Configuration of GDS
  4. Client connectivity test

Summary

We've seen what is the difference between the local data services and the global data services and why the GDS involvement is necessary in heavy organizations, apart from that we have also seen in detail on various components involved to manage GDS and obtaining the GSM software engine and keep ready for the installation.

References

https://docs.oracle.com/database/121/GSMUG/intro.htm