Migration to Exadata Consideration-Instance Caging

-

 For DBA a lot of things need to be consideration when migrating database. In this blog, we will discuss one of the concepts "Instance Caging" for migration and consolidation to Exadata Machine.  

Oracle offers a simple and effective approach to server consolidation called “Instance Caging”. Instance Caging focuses on managing CPUs by limiting the CPU usage of an Oracle database instance.

Where multiple databases are hosted in an Exadata environment, the relative assignment of resources between the two DBRM controllers can be balanced by using Instance Caging.

Instance Caging limits the amount of CPU an Oracle database instance consumes by using the Oracle Database Resource Manager and the cpu_count parameter. The cpu_count parameter specifies the CPU usage limit.

When multiple performance-critical database instances share a server, as in the case of Cummins Engine, the approach the DBA should take would be to partition the CPUs among the database instances, thus shielding them from interfering with each other.


The “Partitioning” Approach

The DBA can also use Instance Caging to partition the CPU resources by ensuring that the sum of all CPU limits does not exceed the total number of CPUs. For example, if 4 database instances share a 32 CPU server, then their limits can be set to 16, 8, 4, and 4, as shown in the following illustration.






By dedicating CPU resources to specific database instances, partitioning provides two advantages leading to more predictable performance:
Ø one database instance’s CPU load will not affect another’s
Ø each database instance’s available CPU resources is fixed

Instance Caging can be configured to support each of these controls:

1. Minimum CPU allocation. For each database instance, the DBA can configure the minimum amount of CPU that the database instance will be able to consume.

2. Maximum CPU allocation. For each database instance, the DBA can configure the maximum amount of CPU that the database instance can consume.

3. CPU shares. CPU shares specify the relative amount of CPU allocated to a database instance. At any moment in time, the CPU allocation for a database instance can be computed by dividing its share by the total number of shares from database instances that need CPU resources.


 You can learn in detail on Exadata from book Expert Oracle Exadata  

==========================================================

Please check our other blogs for Exadata. 



Location: Singapore

Comments

Post a Comment

Please do not enter any spam link in comment Section suggestions are Always Appreciated. Thanks.. !

Popular posts from this blog

Restart Innodb MySQL Cluster after Complete outage(All node Down)

-
Image
Restart Innodb MySQL Cluster after Complete outage(All node Down) In DBA World, Their could be activity(like DC Migration) where all node of an MySQL Innodb cluster need to brought down. In MySQL Innodb cluster, We need to follow below steps in order to bring up cluster. 1) Start all node in the MySQL Innodb cluster. systemctl start myql 2) Try to connect cluster using mysqlsh and check status. 3) Strat cluster using complete outage command. Restart Cluster using below command: var cluster = dba.rebootClusterFromCompleteOutage(); root@mysqlhost01:~# mysqlsh --uri clusteradmin@mysqlhost01:3306 Please provide the password for 'clusteradmin@mysqlhost01:3306': ************************ Save password for 'clusteradmin@mysqlhost01:3306'? [Y]es/[N]o/Ne[v]er (default No): MySQL Shell 8.0.17 Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of...
Read more

Oracle Block Corruption - Detection and Resolution

-
Oracle Block Corruption - Detection and Resolution Any kind of corruption in database can  lead to stand still operation of the organization and can cause sever impact to organisation. In this blog , We are going to discuss about Block Corruption of the oracle database. Block Corruption :  Oracle Block Corruption occurs due inconsistent block Header ,Footer ,Checksum or Structure. Depending on the kind of insistency ,We can divide corruption into Physical and Logical corruption. Physical Corruption is due to Bad header, header or footer mismatch ,Invalid Block checksum & misplaced block. Usually this kind of the block corruption are due to external reason and difficult to resolve by oracle utilities alone.  Logical Corruption is due to corrupt or invalid Block structure when block checksum is valid. This kind of the Corruption can be resolved by the Oracle Utilities. Detection of Block Corruption Whenever a corrupt block is read Oracle reports an error in the alert l...
Read more

Add or Remove a node in MySQL Innodb Cluster

-
Add or Remove a node in MySQL Innodb Cluster In any database Cluster Solution ,it's regular activity to add or remove node from the cluster. In this blog , We will discuss about addition and removal of the cluster node from the MySQL Innodb cluster. Remove a node from the MySQL Innodb cluster . 1) Connect to primary node and check status. mysqlsh --uri clusteradmin@mysqlhost01:3306 MySQL  mysqlhost01:3306 ssl  JS > cluster.status() {     "clusterName": "mysqlcluster",     "defaultReplicaSet": {         "name": "default",         "primary": "mysqlhost01:3306",         "ssl": "REQUIRED",         "status": "OK",         "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",         "topology": {     ...
Read more