In previous blog, we talked about system-managed sharding. We saw how it is possible to create shard databases with Oracle 12c R2. Below we remind the configuration we used.
VM sharddemo1: catalog
VM sharddemo2: shard
VM sharddemo3: shard
One of the characteristics of sharding is the scalability, and in this blog we are going to add a new shard on a new server. The new configuration will be like below
VM sharddemo1: catalog
VM sharddemo2: shard
VM sharddemo3: shard
VM sharddemo4: shard — New added shard
We supposed that you have already read the first part
After adding the new shard, we will see how we connect in a shard environment.
First let’s confirm that we have only two shards running now (one on server sharddemo2 and one on server sharddemo3):
GDSCTL>config shard
Name Shard Group Status State Region Availability
---- ----------- ------ ----- ------ ------------
sh1 shgrp1 Ok Deployed region1 ONLINE
sh21 shgrp1 Ok Deployed region1 ONLINE
To add the new server sharddemo4 in the sharding environment, we first have to register remote scheduler agent on the newly added shard:
[oracle@sharddemo4 ~]$ which schagent
/u01/app/oracle/product/12.2.0.1/dbhome_1/bin/schagent
[oracle@sharddemo4 ~]$ echo welcome | schagent -registerdatabase sharddemo1 8080
Agent Registration Password ?
Oracle Scheduler Agent Registration for 12.2.0.1.2 Agent
Agent Registration Successful!
[oracle@sharddemo4 ~]$
After registration, let’s start the agent
[oracle@sharddemo4 ~]$ schagent -start
Scheduler agent started using port 16267
We must also create the corresponding directories for the database
[oracle@sharddemo4 ~]$ mkdir /u01/app/oracle/oradata
[oracle@sharddemo4 ~]$ mkdir /u01/app/oracle/fast_recovery_area
We can now launch gdsctl on sharddemo1 and connect with an administrator
[oracle@sharddemo1]$ gdsctl
GDSCTL: Version 12.2.0.1.0 - Production on Tue Mar 07 11:43:44 CET 2017
Copyright (c) 2011, 2016, Oracle. All rights reserved.
Welcome to GDSCTL, type "help" for information.
Current GSM is set to REGION1_DIRECTOR
GDSCTL>
GDSCTL>connect mygdsadmin/root
Catalog connection is established
GDSCTL>
As for existing shards, the new server sharddemo4 must be invited
GDSCTL>add invitednode sharddemo4
We also have to create the shard on sharddemo4. The shardgroup, destination and the credentials should be specified.
GDSCTL>create shard -shardgroup shgrp1 -destination sharddemo4 -credential oracle_cred
The operation completed successfully
DB Unique Name: sh41
GDSCTL>
And then now we can deploy
GDSCTL>deploy
deploy: examining configuration...
deploy: deploying primary shard 'sh41' ...
deploy: network listener configuration successful at destination 'sharddemo4'
deploy: starting DBCA at destination 'sharddemo4' to create primary shard 'sh41' ...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: waiting for 1 DBCA primary creation job(s) to complete...
deploy: DBCA primary creation job succeeded at destination 'sharddemo4' for shard 'sh41'
deploy: requesting Data Guard configuration on shards via GSM
deploy: shards configured; background operations in progress
The operation completed successfully
GDSCTL>
Running command config shard, we can verify that a new sharded database sh41 was created
GDSCTL>config shard
Name Shard Group Status State Region Availability
---- ----------- ------ ----- ------ ------------
sh1 shgrp1 Ok Deployed region1 ONLINE
sh21 shgrp1 Ok Deployed region1 ONLINE
sh41 shgrp1 Ok Deployed region1 ONLINE
Now querying the 3 shards we can see that data for sharded tables are automatically balanced between the SH1, SH21 and SH41
For example we have a total of 15 rows in the catalog ORCLCAT for the sharded table CUSTOMERS that should be distributed between the 3 sharded instances
SQL> select name from v$database;
NAME
---------
ORCLCAT
SQL> select count(*) from customers;
COUNT(*)
----------
15
We have 3 rows for customer table in SH1
SQL> select name from v$database;
NAME
---------
SH1
SQL> select count(*) from customers;
COUNT(*)
----------
3
We have 3 rows for customer table in SH21
SQL> select name from v$database;
NAME
---------
SH21
SQL> select count(*) from customers;
COUNT(*)
----------
3
And 9 rows for customer table in SH41
SQL> select name from v$database;
NAME
---------
SH41
SQL> select count(*) from customers;
COUNT(*)
----------
9
Now that we have our sharded databases, how to connect? We have two ways to do it:
1- Connect to a shard by specifying a sharding_key
2- Connect to the shardcatalog via GDS$CATALOG service
For single-shard queries, we can connect to a shard with a given sharding_key using the shard director. For example let’s display data for table customers in SH41 database
SQL> select firstname,lastname,custid from customers;
FIRSTNAME LASTNAME CUSTID
--------------- --------------- ----------------------------
Seane Tuger Seane.Tuger@localdomain
Seaneis Tugeris Seaneis.Tugeris@localdomain
Seanae Tugera Seanea.Tugera@localdomain
Sophiea Moralesa Sophiea.Moralesa@localdomain
Mourada Habiba Mourada.Habiba@localdomain
Michel Robert Michel.Robert@localdomain
Sophie Morales Sophie.Morales@localdomain
Joe Dalton Joe.Dalton@localdomain
Mourad Habib Mourad.Habib@localdomain
9 rows selected.
If we want to retrieve information about customer Seane Tuger, we can connect directly to shard SH41.
For this we need first to create a global service that runs to all shard databases. This global service will be used with a sharding key
GDSCTL>add service -service my_service_shard_srvc
The operation completed successfully
GDSCTL>
Let’s start the service
GDSCTL>start service -service my_service_shard_srvc
The operation completed successfully
GDSCTL>config service
Name Network name Pool Started Preferred all
---- ------------ ---- ------- -------------
my_service_sha my_service_shard_srvc.cust_sd cust_sdb Yes Yes
rd_srvc b.oradbcloud
GDSCTL>
Now that the service is started, we can use the following connect string which will route us directly to the SH41 because of the SH4ARDING_KEY we specified.
[oracle@sharddemo2 admin]$ sqlplus user_shard/root@'(description=(address=(protocol=tcp)
(host=sharddemo1)(port=1571))(connect_data=(service_name=my_service_shard_srvc.cust_sdb.oradbcloud)
(region=region1)(SHARDING_KEY=Seane.Tuger@localdomain)))'
SQL*Plus: Release 12.2.0.1.0 Production on Tue Mar 7 14:34:48 2017
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Last Successful login time: Tue Mar 07 2017 13:41:56 +01:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> select name from v$database;
NAME
---------
SH41
To perform cross-shard queries, we have to connect to the shardcatalog (coordinator database) using the GDS$CATALOG service (from any shard). GDS$CATALOG is a service automatically deployed in the shardcatalog.
[oracle@sharddemo1 ~]$ lsnrctl services
LSNRCTL for Linux: Version 12.2.0.1.0 - Production on 07-MAR-2017 14:45:14
Copyright (c) 1991, 2016, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sharddemo1.localdomain)(PORT=1521)))
Services Summary...
Service "GDS$CATALOG.oradbcloud" has 1 instance(s).
Instance "ORCLCAT", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:604 refused:0 state:ready
LOCAL SERVER
Via sqlplus we can connect like
[oracle@sharddemo2 admin]$ sqlplus user_shard/root@sharddemo1:1521/GDS\$CATALOG.oradbcloud
SQL*Plus: Release 12.2.0.1.0 Production on Tue Mar 7 14:48:05 2017
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Last Successful login time: Tue Mar 07 2017 14:47:58 +01:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> select name from v$database;
NAME
---------
ORCLCAT
Now that we saw how to connect, we can go further and see how oracle manage queries in a shard environment.
Let’s connect to ORCLCAT database and let’s run a query which does a SELECT query accessing multiple shards on a sharded table and let’s look the execution plan. Such queries are called cross-shard queries (CSQ)
SQL> SELECT FirstName,LastName, geo, class FROM Customers WHERE class like '%free%';
Execution Plan
----------------------------------------------------------
Plan hash value: 2953441084
--------------------------------------------------------------
| Id | Operation | Name | Cost (%CPU)| Inst |IN-OUT|
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 0 (0)| | |
| 1 | SHARD ITERATOR | | | | |
| 2 | REMOTE | | | ORA_S~ | R->S |
--------------------------------------------------------------
Remote SQL Information (identified by operation id):
----------------------------------------------------
2 - EXPLAIN PLAN SET STATEMENT_ID='PLUS470045' INTO PLAN_TABLE@! FOR
SELECT "A1"."FIRSTNAME","A1"."LASTNAME","A1"."GEO","A1"."CLASS" FROM
"CUSTOMERS" "A1" WHERE "A1"."CLASS" LIKE '%free%' /*
coord_sql_id=bkpy0tbjnqu3k */ (accessing
'ORA_SHARD_POOL@ORA_MULTI_TARGET' )
We can see above that the query is using a dblink ORA_MULTI_TARGET to perform CSQ on sharded tables. This dblink is created automatically when the gsm is configured to handle cross-shard querying.
SQL> select owner,DB_LINK,username,host from dba_db_links where owner='USER_SHARD';
OWNER DB_LINK USERNAME HOST
--------------- ----------------------------------- --------------- ---------------
USER_SHARD ORA_SHARD_POOL@ORA_MULTI_TARGET USER_SHARD GDS$CATALOG
Now let’s connect to SH1 and let’s query the duplicated table products and let’s look into the execution plan.
SQL> select * from products where productid>2;
Execution Plan
----------------------------------------------------------
Plan hash value: 1639127380
------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 158 | 0 (0)| 00:00:01 |
| 1 | MAT_VIEW ACCESS BY INDEX ROWID BATCHED| PRODUCTS | 1 | 158 | 0 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | SYS_C007361 | 1 | | 0 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------
We can see that a materialized view is being used. This means that for duplicated tables oracle is using materialized views to handle queries.
Conclusion
In this article we talked about sharding scalability and how to connect to shards. System-managed sharding was used. In coming articles, we will talk about other sharding methods like composite and user-defined sharding. We will also talk how it is possible to combine sharding and dataguard.
Cet article Sharding with Oracle 12c R2 Part II : Scalability and Connections est apparu en premier sur Blog dbi services.