BEHIND & BEYOND INDEXES

ORACLE PERFORMANCE TUNNING

Objective of this document is overcome oracle performance issues BEYOND

indexing. Does not cover much tuning using index techniques.
What is causing modern day performance issues?

Database Performance is ever increasing challenge because of continues increase in

business data volume, data retention & the way data is looked in modern era for analytical /
analysis purpose.

In context to Telco world, new customer addition / usage is surged because of new
technologies leads to cost reduction, new products innovation. This exponentially increase
business volume.
Modern day technologies like ‘Data Science ‘ , ‘Data Analytics’ & ‘Revenue Assurance
Systems’ demands more retention duration than before for better processing to arrive very
accurate customer needs or gain business advantages.

Companies having Global presence faces huge challenges in terms of data retention.
Each country demands its own data retention policy, in many cases it is up to 2 years.
Companies are moving towards building single operational stacks to reduce software
development, maintenances & operational costs. This can be achieved by moving all global
customer data processing into single platforms. This leads to huge data
accumulation/processing in single databases.
How to overcome modern day performance issues?

Even though, Oracle database is very robust ORDBMS designed considering all
objective of modern era business. These benefits will be inherited only when we adopt right
features for each of the performance issues.
Since growing/ frequent change in requirements, it is required design databases with
combination of features to achieve multiple objective and easy to adopt changes with
minimal impacts.

Database performance can be achieved in various level.

Database configurations: Tuning database parameter to application requirements,
adopting multi server processing capabilities ( RAC deployment ), Adjusting RAC
configurations by creating application specific SERVICES to control Block shipment & use of
SCAN-IP’s to distribute load across the RAC Nodes , PARALLEL Transitions, INDEXES ,
enforcing HITS, Table/Index PARTITIONS, OS level via HUGEPAGES configuration.

SQL & PLSQL Performance: making use of right Joins, Analytical functions and Bulk
collection.
More on analytical functions https://oracle-base.com/articles/misc/analytic-functions
Performance Gains using Indexes.
Traditionally performance issues are overcome through INDEXES. Indexes are
transparent to transactions, but overhead on resource like CPU, Disk I/o’s.

Below are the typical indexes are choose based on the nature of the application.

B-Tree Indexes
BITMAP indexes
Function Based Indexes
Reverse Key Indexes
Unique Indexes
Index Organized Tables (IOT) **
Foreign key Indexes **
Global & local Indexes**
Global Partition indexes**
** B-Tree Types
To Gain maximum performance, index should be designed with SELECTIVITY of 1. More
on Index selectivity http://www.firebirdfaq.org/faq167/

Myths about BITMAP Indexes: Suites for low cardinal columns.

Should be caution on choosing BITMAP Indexes, they can cause huge locking issues when chosen in High
transactional DB (OLTP environments). For example, in your situation with the column that has only 2 distinct
values, if this value is being updated, the part of the index that corresponded to its old value is locked (which
may effectively lock 50% of the rows in the table). If someone else is trying to update another of those records
(even if it is a different column) you may see long waits for locks.
Performance Gains Using RAC Configurations

As a standard practice, 2 nodes RAC deployment is rolled out in production

deployments. This gives great flexibility of distributing workload to multiple servers with no
change in application configuration. This enhances processing capacity of application. But
application should be designed for RAC aware. This means, large concurrent transactions/
un-optimized reads can pull large amount of blocks into memory and sessions on another
nodes demanding same set of blocks should wait. In simple we can call it as ‘Block
contentions’. This problem is wider as number of nodes are large in RAC.
More on wait event http://www.dba-oracle.com/art_builder_bbw.htm

This can be partially overcome with multiple DB Services configurations. DB services

with different Preferred / available node configuration can result in pinning connections to
particular nodes. Specific application functionality does read-write on high translational
tables will always be connected to Node-1 and reporting services demands large reads on
archive tables should be severed from node-2.
srvctl add service -d racxx_primary -s rac_i01 -l PRIMARY -y AUTOMATIC -r node1 -a node2
srvctl add service -d racxx_primary -s rac_i02 -l PRIMARY -y AUTOMATIC -r node2 -a node1

Above such service configuration suppress RAC load balancing flexibility but resources (CPU/Memory) are
undisturbed due to bad performance of the other node.

BT Examples

BFG server many of customer facing application like GS Portal, Ordering, ticketing, ITSM, NGSD and many of
Inventory management systems AGORA, COT+, SMARTS, GSEDW etc.

Business critical application are always hosted on node-2 and all other inventory management interfaces are
mapped to node-1. This ensure node-2 resources are always reserved for BAU critical applications , not
impacted due to any high resource intensive operation on node-1. This configuration also gives opportunity
stop any interface by stopping particular service, say if AGORA is having issues, we can stop this interface by
stopping AGORA mapped service.