Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
O RACLE A ND I NFORMATICA
Page 1 of 54
TABLE OF CONTENTS
TABLE OF CONTENTS...............................................................................................................................2
DOCUMENT PURPOSE...............................................................................................................................4
SECTION 1: TUNING OF INFORMATICA SERVER AND MAPPINGS..............................................5
1.1 SUGGESTED INFORMATICA SERVER CONFIGURATION.............................................................................5
1.1.1 PMServer Configuration.................................................................................................................5
1.1.2 Repository Server Configuration....................................................................................................6
1.1.3 Informatica Environment configuration..........................................................................................7
1.2
INFORMATICA SERVER TUNING FRAMEWORK...................................................................................8
1.3
INFORMATICA MAPPING TUNING FRAMEWORK................................................................................9
1.3.1
Tuning Goal..............................................................................................................................9
1.3.2
Mapping Tuning Steps..............................................................................................................9
SECTION 2: TUNING OF ORACLE SERVER AND APPLICATION COMPONENTS....................13
2.1 DEFINING THE TUNING SCOPE AND EFFORT ESTIMATION......................................................................14
2.3 THE TUNING PROCEDURE.....................................................................................................................15
2.3.1 Instance Optimization...................................................................................................................15
2.3.1.1 SGA Parameters......................................................................................................................15
2.3.1.2 I/O Parameters........................................................................................................................17
2.3.1.3 Sort Parameters.......................................................................................................................18
2.3.1.4 Parallel Query Parameters......................................................................................................18
2.3.1.5 Oracle Parallel Server Parameters..........................................................................................18
2.3.1.6 OS Specific Parameters..........................................................................................................18
2.3.1.7 Contention Issues....................................................................................................................19
2.3.2 Space Management.......................................................................................................................21
2.3.2.1 Categorization of tablespaces Small extent, Medium extent, Large extent.........................21
2.3.2.2 Organization of tablespaces multiple data files on different drives....................................21
2.3.2.3 Table space fragmentation Internal / External.....................................................................22
2.3.3 SQL Reuse Opportunities..............................................................................................................22
2.3.4 Optimal Data Access with suitable object placement...................................................................22
2.3.5 Query Tuning -- Concepts.............................................................................................................24
2.3.5.1 Optimizer Approach / Goal....................................................................................................24
2.3.5.2 Full Table Scans Vs Range Scans...........................................................................................27
2.3.5.3 Index Scan Types....................................................................................................................28
2.3.3.5 Join Types...........................................................................................................................30
2.3.4.5 Stats Collection...................................................................................................................33
2.3.6 Query Tuning - Steps.....................................................................................................................34
2.3.6.1 Using Hints Overview.....................................................................................................34
2.3.6.2 Optimizer Approach / Goal Hints.......................................................................................35
2.3.6.3 Hints for Access Paths........................................................................................................36
2.3.6.4 Hints for Query Transformations........................................................................................37
2.3.6.5 Hints for Join Orders..........................................................................................................38
2.3.6.6 Hints for Join Operations....................................................................................................39
2.3.6.7 Hints for Parallel Operations..............................................................................................40
2.3.6.8 Miscellaneous Hints...........................................................................................................41
Page 2 of 54
REFERENCES.....................................................................................................................................42
APPENDIX A................................................................................................................................................43
APPENDIX A.1 PMSERVER CONFIGURATION FILE...................................................................................43
APPENDIX B ORACLE STATS COLLECTION APPROACH..........................................................45
B.1 STATS COLLECTION...........................................................................................................................45
B.2- ORACLE STATS ANALYTICS.................................................................................................................46
Page 3 of 54
Document Purpose
This document has been prepared for the DW BI practice of the e-Enabling group (Finance & Securities)
with the following objectives:
Tune Informatica server and mappings by employing the suggested framework and best practices.
Tune Oracle server and components by employing the suggested framework and best practices.
The document is structured as under:
Page 4 of 54
8 CPU SMP box, to ensure a maximum of 8 partitions without any appreciable depreciation in
scale up.
1 GB RAM dedicated to each of the processor (8 GB RAM in total)
High-speed swap space of at least 40 GB mapped to the CPU bank. This ensures that
$PMCacheDir is mapped to a high-speed swap space instead of mounted drives. Empirical tests
conducted on effects of high-speed swap Vs. mounted drives have shown paging performance gain
of about 20%.
At least, 10 Mbps network connectivity between Informatica server, clients, file systems and data
base servers.
# Absolute or relative path of the file where the LM will write its messages.
LogFileName=/path/<Rep Name>/pmserver.log
drive */
# Determine one of the two server data movement modes: UNICODE or ASCII.
# If not specified, ASCII data movement mode is assumed.
DataMovementMode=ASCII /* Unless we are processing multiple languages, ASCII mode
is ok from performance perspective */
# Maximum number of sessions Based on our peak time requirement. Set it 20% over
the maximum concurrency requirement to account for processing first time failures.
MaxSessions=200
# Load Manager (pmserver) shared memory, in bytes
# For each 10-count increase of MaxSessions, increase this by 2000000 bytes
LMSharedMem=40000000
# Obsolete parameter PMCacheDir: PowerMart Cache directory location
Page 5 of 54
The above Rep Server configuration has performed well in a very demanding computational environment.
Page 6 of 54
Page 7 of 54
Criteria
Single partition write throughput on a nonconstrained table
Single partition write throughput on a
constrained table (key constraints, row level
trigger for sequence number generation)
Single partition read throughput from a flat file
located on the network file system
Metadata load and session initialization
Mapping 1 Read 20 attributes from very large
flat file (1 GB +, 30 million records), group by
10 ports in an aggregator transform and dump
the output to a flat file (/dev/null).
Mapping 2 Read 20 attributes from very large
table (30 million records), group by 10 ports in
an aggregator transform and dump the output to
a flat file.
Mapping 3 Read 20 attributes from very large
table (30 million records), perform lookup on a
set of very large lookups (> 1 million) that have
default data cache and index cache of 2MB and
1 MB respectively. Dump data to a flat file
Scalability Test Estimation of performance by
going in for multiple partitions
Measures
7000 rows/sec
2500 rows/sec
12000 rows/sec
Under 1 minute. Repository database server is connected
to the Informatica server via a 10 BASE T network
connection (10 mbps)
Read throughput 10000 rows/sec
Time to build aggregator cache 50 minutes
Total execution time 80 minutes (single partition)
Read throughput 6000 rows/sec
Time to build aggregator cache 90 minutes
Total execution time 120 minutes (single partition)
Read throughput 4000 rows/sec
Time to build 4 lookup caches 10 minutes
Stabilized write throughput 3800 rows/sec
Total execution time 150 minutes (single partition)
20 % depreciation owing to thread communication and
maintenance overhead observed. This means that for 2
partitions, performance will improve by 1.6 times.
We can also look for ways to improve the above-mentioned metrics by experimenting the parameters of the
configuration file, network connectivity etc. By evaluating the above-mentioned criterion, we are seeking
to determine:
Optimal DB Write throughput (Can also be improved by increasing the TNS packet size)
Optimal DB Read throughput
Repository Database access efficiency
Aggregation efficiency
Paging efficiency
Server scalability for multi-partition session execution
The above metrics have been obtained on 24 CPU, 24 GB RAM Sun Fire E6800 machine with 80GB highspeed swap drive. We can benchmark the server-operating environment along the criteria mentioned above.
This will give us the best-case run time estimates of the mappings/sessions before we tune them.
Page 8 of 54
Page 9 of 54
Tuning Goal
We should first set a realistic execution time for the mapping that is to be tuned. It can be done by:
Volume read by the source qualifier time taken to read it using the best case read throughput
estimated in Section 1.2.
Volume written by the mapping to the relational/ flat file target time taken to write to the target
using the best case write throughput estimated in Section 1.2.
Time taken to build the aggregator cache estimated on the basis of results obtained in Section 1.2.
The execution time estimated above happens to be the best-case single partition run time for the mapping
with its existing design. At this point, we may want to appraise the choice of transforms (AGG, LKP, JNR)
used in the mapping. We can look into the possibility of using LKP for aggregation instead of an AGG
transform, SQL join instead of a LKP or JNR.
If the processing logic does not allow for innovations prescribed above, then we have to look into the
possibility of tuning the transforms used in the mapping and reach closely to the best case running time as
calculated above.
Note Partitioning of the mapping should be done only after tuning the constituent transformations of the
mapping.
1.3.2
Transformation tuning: Database queries LKP SQLs, Source Qualifier SQLs, UPDATE strategy
override SQLs. Use SQL tuning details presented in Section 2.3.6.
Transformation Cache sizes AGG, JNR, LKP, SRTR transforms.
DB Write on tables Storage properties of the table object, TNS packet configuration.
Session properties Block buffer, DTM buffer, Commit interval, Partition points, Session
partitioning.
Transformation tuning: Database queries LKP SQLs, Source Qualifier SQLs, UPDATE
strategy override SQLs
Database queries should be tuned, re-written to get the best possible throughput. For details on query
tuning, please refer to Section 3.3.6 of the document.
As lookup caches are built in serial, we need to minimize the time spent in building the caches. So, we
should aim for retrieval of all records from the database as quickly as possible.
We can also customize the UPDATE strategy with adequate WHERE clause and hints to speed up the
process.
We should also seek to do all data validations and transformations in the SQL query itself (applicable with
relational sources). Examples for the same are as under:
decode(nvl(company_code,'0000'),
Page 10 of 54
10
'','0000',company_code)asCOMPANY_CODE
Such clauses ensure that we do not do any data validations in EXP transform with IIF function calls.
We should write our transformation logic that avoids warning messages in the session log, like:
TE_7004 [<<PM Parse Warning>> [SUBSTR]: operand converted to a string
... IIF(substr(>>>>Attribute Name <<<<, 0, 5) = '28695', (Attrib Name 1 Attrib Name2) *
-1, (Attrib Name3 Attrib Name4) * -1)]
In order to curb such warning messages, we can model expression transform port logic like:
IIF(group_num_for_lkp = -1, in_pp_indicator, IIF(amt_for_lkp >= 0 AND substr(in_acct, 1, 1) <> '1', '08',
IIF(amt_for_lkp < 0 AND substr(in_acct, 1, 1) <> '2', '08',in_pp_indicator)))
By simplifying substr(in_acct, 1, 1) <> '1' and substr(in_acct, 1, 1) <> '2' at the database level itself by
firing this as part of extra ports in the source qualifier of the mapping
Example: Additional flag port in the SQ can be
decode(substr(IN_ACCT,1,1),'1','ONE_ACCT','2','TWO_ACCT','OTHER')asacct_type
This can in turn be used in the port logic, thus speeding up the transform (minimizes function calls in
Informatica).
We can also eliminate ISNULL checks by doing the same in the SQ by devoting an additional port for the
same.
Example: Additional flag port for null check on an attribute can be like:
Decode(IN_ACCT,null,'NULL','NOT_NULL')asnull_ind
This will allow us to prevent null checks like ISNULL (IN_ACCT) on the Informatica side. In a nutshell,
we should always look for ways to minimize Informatica transformation language function calls as much as
possible.
Transformation bottlenecks are also caused due to use of Aggregator transform in the mapping. We can also
explore the possibility of using LOOKUP transform for aggregation purposes. This will speed up
performance dramatically.
SELECTsum(nvl(t1.AMT_USD_EQV,0))asAMT_USD_EQV,
decode(nvl(t1.COMPANY_CODE,'0000'),'','0000',COMPANY_CODE)asCOMPANY_CODE,
nvl(t2.Credit_Line_Id,'')asCredit_Line_Id,
nvl(t2.Credit_Source,'')asCredit_Source
FROM
Table1t1,
Table2t2,
RulesTableRT
WHERE
SetofConstraints
GROUPBY
decode(nvl(t1.COMPANY_CODE,'0000'),'','0000',t1.COMPANY_CODE),
nvl(t2.Credit_Line_Id,''),
Page 11 of 54
11
nvl(t2.Credit_Source,'')
We can also use Filter transform (if applicable) as close to the SQ of the mapping. We should also explore
the possibility of performing single pass read as much as possible.
Page 12 of 54
12
For very large lookups, aggregator, joiner and sorter caches, it is not possible to allocate enough RAM in
order to prevent paging. But, we can always minimize the effects of paging by:
o
o
o
Allocating large amount of RAM for index caches as compared to data caches. This will
minimize effect of paging on index cache. This will improve transformation performance.
Having high speed swap space for $PMCacheDir and not mounted network drives.
Going in for 40-60 rule Have 40% in RAM and remainder in swap space for data and index
caches.
We can also review the order in which comparison is made in the condition port of LKP transform. This
also helps in optimal formation of the index cache and improves performance of the LKP transform.
I/O contention on the underlying tablespace datafiles of the table. A quick way to check it is
by firing the following query during high activity time slices:
selectd.name,f.phyrds,f.phywrts
from
v$datafiled,
v$filestatf
whered.file#=f.file#
andf.phyrds>100000andf.phywrts>100000
o
o
o
Too many concurrent writes on set of tables belonging to the same table space. In such
scenarios, it is useful to consider multiplexing a set of table objects on a set of table spaces.
In case of multiple partitions writing on the same table object, we should review the
INITRANS parameter of the table object. We should increase it to a value between 10-20 to
allow for adequate concurrency.
We should also examine the possibility of going in for uniform extent management in the
storage clause of the table object. In case of large volume batched inserts, it allows for fewer
extent allocation cycles at run time. A desirable STORAGE clause of table objects could be:
INITRANS 10 /* To support adequate concurrency */
MAXTRANS 255
STORAGE (
INITIAL 10M
NEXT 10M
PCTINCREASE 0 /*Uniform extent management with large extent size */
MINEXTENTS 1
MAXEXTENTS 2147483645
)
Have fewer data validation constraints at the data base level. We may not want to have NOT
NULL DEFAULT value constraints on non-key columns and instead have such validations
built into the mapping itself.
Page 13 of 54
13
For minimizing flat file bottlenecks, we may want to stage data local to the Informatica server and then
FTP to the desired location.
Session properties Block buffer, DTM buffer, Commit interval, Partition points, Session
partitioning
o
o
o
o
Line Sequential Length 1024 bytes by default. Consider increasing it when the row size of
the SQ of the mapping has greater than 1024 bytes.
Block buffer In large volume mappings, we can increase it to 128K from default 64K
DTM buffer In large volume mappings, we can consider increasing it from default value of
12MB.
Commit interval In order to utilize large DTM buffer allocations; we should increase the
commit interval to a large value from its default setting of 10,000 rows. This will ensure that
we have fewer database write cycles at run time. Study the session log to see the number of
DB Write cycles.
Partition points We can consider introducing partition points at appropriate stages of the
mapping pipeline if existing default partition point threads show a utilization percentage of >
50%. We should also check for new partition point thread utilization percentage. If it is lower
than 20% then we should re-consider having a partition point at that stage in the pipeline.
Session partitioning As a general rule, partition count should not be greater than the CPU
bandwidth. Data should be partitioned on a key that divides uniform number of records across
partitions.
Page 14 of 54
14
SECTION 2: Tuning
components
of
Oracle
Server
and
Application
This section provides actionable information for tuning the highest impact database performance areas,
such as:
Balancing the different types of competing resources in the database environment so that the most
important applications have priority access to the resources they need to use.
Taking advantage of database features for the types of work performed on the database
Tuning an Oracle application /server usually follows the logical steps mentioned below:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Decisions made in one step are also likely to impact other steps. For example Rewriting an SQL in Step 5
may have significant bearing on parsing and caching issues addressed in Step 7.
Page 15 of 54
15
Tuning Scope
Application Tuning
Instance Tuning
Space Management
Instance
Optimization
Space
Management
SQL
Reuse
Data Access
By Table
Data Access
by workload
Amount of data
to collect
Time required to
collect data
Impact
of
collection effort
on database
Manual
effort
required
to
collect/ edit data
Potential
complexity
of
implementing
tuning
recommendations
Potential
gain
from
implementing
tuning
recommendations
Small
Small to
Medium
Short to
Medium
Low
Small to
Large
Short to
Long
Low
Small to
Large
Short to Long
Negligible
Medium to
Large
Medium to
Long
Low
Low
Low
Low
Low
Low
Low to High
Low
Low
Low
Low
Low
Low
Low
Low
Medium
Medium
Medium
Medium to
High
Medium to
High
Medium
Short
Data Access
Index
Rebuild
Small
Short
Based on project realities, we can define the tuning scope as illustrated above.
Page 16 of 54
16
Page 17 of 54
17
We can see the current SGA size for a database by executing the following query:
selectname,bytesfromv$sgastat
SGA size can be altered by modifying the following parameters in init.ora:
DB_BLOCK_BUFFERS The number of database blocks (of size DB_BLOCK_SIZE) allocated to the
database buffer cache.
LOG_BUFFERS The size in bytes of the redo log buffer.
SHARED_POOL_SIZE The size in bytes of the shared SQL area.
The database buffer cache is the memory buffer within the SGA that holds copies of data that has been read
and often changed from the physical database files. There are as many buffers in this buffer cache as the
value of DB_BLOCK_BUFFERS. They include:
Dirty Buffers Buffers that have been changed but not written back to the disk
Pinned Buffers Buffers that are currently been accessed.
Free Buffers - Buffers that are available for use
It is desirable to have Oracle work within the SGA memory area as much as possible, the hit rate within the
database buffer cache should be very high usually >70%.
selectname,value
fromv$sysstat
wherenamein('consistentgets','dbblockgets','physicalreads')
Hit Ratio = 1- (physicalreads/(consistentgets+dbblockgets))
Shared SQL cache Used to retain previously executed queries, procedures, and other SQL-based
operations in the SGA.
Data dictionary cache It contains calls made to the data dictionary, which must be done before
every single action in the database.
As with the database buffer cache, the efficiency of the shared pool cache is determined by a hit ratio that
indicates how often the Oracle RDBMS can process information in memory and how often it must retrieve
information from disk. The database should work as much from memory as possible before going to the
disk. Although this is not always practical but then we must record their values during high activity time
slices and see whether they are within acceptable limits.
The following script compares the number of pins (how often an item was executed) to the number of
reloads (how often a miss occurred):
selectsum(pins)pins,sum(reloads)reloads
fromv$librarycache
Page 18 of 54
18
It is relatively easy to change the SGA parameters, but we also need to consider the ramifications of making
changes.
The most obvious benefit of increasing the size of the SGA is that the larger the SGA, the more information
can be processed in memory. By enabling the database to have most of its data cached, physical disk I/O is
minimized, which results in a system that is constrained more by the CPU speed than by the speed of the
I/O devices. The law of diminishing marginal utility applies, however. Depending on the size of the
database and the amount of activity being performed, increasing the size of SGA buffers ceases to have any
positive effect after a certain point. After this occurs, the database begins to hoard memory that could have
been better utilized by other OS processes or applications.
There are some SGA parameters (e.g. Sort Area) that incur memory per user connection. It is also
possible that some SGA setting actually artificially induce paging and swapping onto the system. The
following guidelines may be useful during iterative tuning of SGA parameters:
SGA should fit comfortably in available RAM (not VM) without starving other
processes/applications
Buffer size should not be larger than they need to be.
Watch out for database parameters that incur use for every user such as, SORT_AREA_SIZE.
Setting them too high a value can induce paging/swapping.
We need to be careful about parameters that can cause changes in other parameter values (e.g.
Database block size).
While making changes to the SGA, one needs to account for factors like how fast the database is
growing (size plus user connections).
Page 19 of 54
19
SORT operation is performed by the database when the SQL query has explicit clauses like GROUP BY
and ORDER BY operation. It is also performed implicitly in case of index creation. Internal sorting
(performing the sorting in memory) is always faster than external sorting (performing the sorting in disk).
Whenever an operation is undertaken that requires sorting, Oracle attempts to do it in the memory of the
user process that requests the sort. Sorts are constrained by the following init.ora parameters:
SORT_AREA_SIZE The maximum amount of space in bytes that a user process has available to perform
a sort.
SORT_AREA_SIZE_RETAINED The minimum amount of space in bytes that a user process will ever
have available.
Exceeding sort area size, causes the sort to occur on disk. When no space in the memory is available for the
sort area, Oracle resorts to using the designated temporary table space for sorting operations.
The following script allows us to see whether the sorting is performing efficiently:
selectname,value
fromv$sysstat
wherenamelike'sort%'
Because of large volumes of data typically processed, it is impossible to prevent external sorting. At best
we can have optimal usage of sort area in memory.
Page 20 of 54
20
Contention among physical devices is the most common type of contention. A database is made of several
data files that can reside on the same physical disk drive. If the database requests access to several data files
on the same disk, the result is contention as multiple requests need to be serialized (wait).
We have the following types of database files:
o
o
o
o
In general, we have multiple files that need to be placed on smaller number of available disk drives. It pays
to put the following files on a physical disk separate from other database files:
o
o
o
Rollback segments
Redo Logs
Archive Logs
Page 21 of 54
21
It is also important to optimize their physical layout so that contention is minimized between the ARCH,
DBWR, and LGWR processes. It is also useful for I/O balancing that we put index and table files on
separate devices.
We also need to pinpoint which database files are accessed most heavily and spread them across disks to
balance the load. We can issue the following SQL to determine the I/O load on the database files. We need
to take readings during low activity, medium activity and high activity time slices to arrive at a more
realistic picture.
selectd.name,f.phyrds,f.phywrts
from
v$datafiled,
v$filestatf
whered.file#=f.file#
Apart from examining the possibility of moving a data file from one drive to another, Oracle also gives the
option of stripping a data file into multiple smaller files. Striping enables the database to distribute its data
across the disks, and it speeds I/O access by minimizing contention against disk drives.
A transaction that physically changes data INSERT, UPDATE, DELETE SQL statement, produces
information that Oracle writes to its online rollback segments. As Oracle attempts to provide data
consistency when a query is issued, SELECT statements use rollback segments when they access data
(Read and write on the same partition also thus cause contention). When a query is issued, if a row has
changed but not committed, Oracle returns information from the rollback segments to provide read
consistency. Rollback segments are also used when an instance is forced down or ended with an abnormal
termination.
Rollback segment contention can occur whenever a transaction accesses a block within a rollback segment
that another rollback segment needs. We can use the query below to determine the amount of contention
being experienced within the rollback segments.
selectr.name,s.gets,s.waits
fromv$rollstats,v$rollnamer
wheres.usn=r.usn
The following ratio compares how often a rollback segment was accessed with how often the database
waited to access information with a rollback segment:
Ratio = (waits/gets) * 100
If the ratio >=2, there is contention within the rollback segments. To alleviate this, we may consider
increasing the number of rollback segments.
The size of rollback segment per transaction depends upon the nature of transaction (large volume inserts/
deletes without intermediate commits are quite taxing on the rollback segment usage).
Like tables, rollback segments are constrained by the maximum extent size to which they can grow and by
the amount of physical space available in the table space. Once these limits are reached, the database does
not use a new rollback segment. Therefore, if a rollback segment or its table space is sized incorrectly, it is
possible that the amount of rollback space needed will exceed the total size of the rollback segment.
Page 22 of 54
22
A buffer cache area is in the SGA for redo log information. This information is stored in memory and
regulated through the use of two latches or RAM-level locks. The redo allocation latch controls the
allocation of space for writing redo log information to the buffer. The redo copy latch is used to copy
information to the buffer.
The wait latch requests wait to make a request, sleep, and then make a request again until it acquires the
latch. Conversely, the immediate latch requests do not wait; instead they continue processing. We can use
the following query to determine the status of both types of latches:
selectname,gets,misses,sleeps,immediate_gets,immediate_misses
fromv$latch
wherenamein('redoallocation','redocopy')
Immediate contention = (immediate_misses / (immediate_gets + immediate_misses))*100
Wait contention = (misses / (gets + misses))* 100
If either value is greater than 1, contention is happening for that latch. To alleviate contention for a redo
allocation latch, reduce the amount of time that a latch is held by a process by lowering the value of the
LOG_SMALL_ENTRY_MAX_SIZE parameter in the init.ora file. To alleviate contention for a redo copy
latch, increase the number of latches by raising the value of the LOG_SIMULTANEOUS_COPIES
parameter in the init.ora file.
Page 23 of 54
23
STORAGE
(
INITIAL10M
NEXT10M
PCTINCREASE0Indicatesuniformextentmanagement
MINEXTENTS1
MAXEXTENTS2147483645
)
For static tables, it is useful to have small initial extent size (1K). For medium volume tables (100,000
500,000 records), we can have initial extent size of 1M and for large volume tables (> 1 million), it is better
to go for initial extent size of 10M. It will also be useful to have separate table spaces based on the above
mentioned table volume classification.
It is also desirable to follow consistent extent definition for a table space. If recovery is not a very
important goal, then it is better to go for NOLOGGING option.
If the data object undergoes frequent inserts/deletes, then we can have appropriate maintenance routines to
rebuild indexes and coalesce extents in the data tablespace.
Desired goal Achieve 5000-6000 rows/sec write throughput on moderately constrained table per
Informatica partition; 2000-2500 rows/sec for highly constrained table (indexes and data validation
constraints).
Page 24 of 54
24
selecta.owner,segment_name,segment_type,
sum(bytes),max_extents,count(*)
fromdba_extentsa,dba_tablesb
wheresegment_name=b.table_name
havingcount(*)>3
groupbya.owner,segment_name,segment_type,max_extents
orderbya.owner,segment_name,segment_type,max_extents
INDEXFRAGMENTATION
selecta.owner,segment_name,segment_type,
sum(bytes),max_extents,count(*)
fromdba_extentsa,dba_indexesb
wheresegment_name=index_name
havingcount(*)>3
groupbya.owner,segment_name,segment_type,max_extents
orderbya.owner,segment_name,segment_type,max_extents
We can analyze the poor performing SQL statements ratio of physical reads per execution. This points to
the possibility of fragmentation of the underlying indexes used in the execution plan.
Identify scope for creating additional indexes, drop sparsely used indexes
We should create indexes on tables with option to specify its usage. This allows us to know indexes that are
heavily used and those that are sparsely used. It allows us to evaluate our existing indexing strategy.
Over time, database performance can be affected by problems such as row chaining and/or migration and
index stagnation. This can affect data access and can affect performance. We can reorganize
Page 25 of 54
25
We will need to resort to this option (maintenance intensive) if there we encounter the following situations:
If an UPDATE statement increases the amount of data in a row so that the row no longer fits in its data
blocks, the Oracle Server tries to find another block with enough free space to hold the entire row. If such a
block is available, the Oracle Server migrates the data for the entire row to the new data. A forwarding
address is left at the original rows block. This is called migrating a row; the rowid of a migrated row does
not change.
The effect of row fragmentation on performance is that each time a migrated row is needed for a query, an
additional I/O call is required for the row piece that is not stored in the original block. It is possible to
minimize unnecessary row fragmentation for a table by correctly setting the tables PCTFREE value. Being
too pessimistic on PCTFREE can waste some space but will more or less guarantee no row migration while
being too optimistic can result in row migration and reduced performance.
Reorganizing the table or table partition will fix migrated rows.
Disorganized indexes
As indexed values are inserted or deleted, the amount of unusable space within the index increases.
Because the index contains a mixture of data and empty areas, scans of the index are less efficient.
Rebuilding the index will eliminate unused index space.
In order to avoid unnecessary I/O for objects that are fully scanned, a segments extent size should be a
multiple of the multi-block I/O size which is defined as DB_FILE_MULTIBLOCK_READ_COUNT *
DB_BLOCK_SIZE. If unnecessary I/O is being performed, we can consider rebuilding the object
specifying an INITIAL and NEXT value that is a multiple of the multi-block I/O size.
Overextended object
The MAXEXTENTS storage parameter specifies the maximum number of extents that can be allocated to
the segment. Once a segment has filled the maximum number of extents, any row insertion will fail. If an
object is approaching its maximum extents setting, we can consider increasing the value of the segment's
MAXEXTENTS storage parameter, or rebuilding the segment with a larger extent size. Ensure that the
extents within the segment are the same size by specifying storage parameters where the INITIAL and
NEXT values are the same and PCTINCREASE=0.
Page 26 of 54
26
Index Scans
Join Types
Stats Collection
2.3.5.1 Optimizer Approach / Goal
The execution plan produced by the optimizer can vary depending on the optimizers goal. Optimizing for
best throughput is more likely to result in a full table scan rather than an index scan, or a sort merge join
rather than a nested loops join. Optimizing for best response time, however, more likely results in an index
scan or a nested loops join.
Based on application needs, we choose the optimizer approach/ goal. The following guidelines may be
useful:
For applications performed in batch, such as Oracle Reports/ETL applications, we need to optimize for
best throughput. Usually, throughput is more important in batch applications, because the user
initiating the application is only concerned with the time necessary for the application to complete.
Response time is less important, because the user does not examine the results of individual statements
while the application is running.
For interactive applications, such as Oracle Forms applications or SQL*Plus queries, we need to
optimize for best response time. Usually, response time is important in interactive applications,
because the interactive user is waiting to see the first row or first few rows accessed by the statement.
The optimizers behavior when choosing an optimization approach and goal for a SQL statement is affected
by the following factors:
o
o
o
o
Page 27 of 54
27
Optimization Parameter
Optimization Behavior
CHOOSE - The optimizer chooses between a cost-based
approach and a rule-based approach based on whether statistics
are available.
If the data dictionary contains statistics for at least one of the
accessed tables, then the optimizer uses a cost-based approach
and optimizes with a goal of best throughput.
If the data dictionary contains only some statistics, then the costbased approach is used, and the
optimizer must guess the statistics for the subjects without any
statistics. This can result in suboptimal execution plans.
If the data dictionary contains no statistics for any of the accessed
tables, then the optimizer uses a rule-based approach. This is the
default value.
ALL_ROWS - The optimizer uses a cost-based approach for all
SQL statements in the session regardless of the presence of
statistics and optimizes with a goal of best throughput (minimum
resource use to complete the entire statement).
OPTIMIZER_GOAL
SESSION Statement
Parameter
of
the
ALTER
Page 28 of 54
28
The statistics used by the CBO are stored in the data dictionary.
We can collect exact or estimated statistics about physical storage
characteristics and data distribution in these schema objects by
using the DBMS_STATSpackage or the ANALYZEstatement.
To maintain the effectiveness of the CBO, we must have statistics
that are representative of the data. It is possible to gather statistics
on objects using either of the following:
For table columns that contain skewed data (in other words,
values with large variations in number of duplicates), we should
collect histograms.
The resulting statistics provide the CBO with information about
data uniqueness and distribution. Using this information, the
CBO is able to compute plan costs with a high degree of
accuracy. This enables the CBO to choose the best execution plan
based on the least cost.
Notes:
Cost - The cost represents units of work or resource used. The CBO uses disk I/O,CPU usage, and
memory usage as units of work. So, the cost used by the CBO represents an estimate of the number of
disk I/Os and the amount of CPU and memory used in performing an operation. The operation can be
scanning a table, accessing rows from a table using an index, joining two tables together, or sorting a
row set. The cost of a query plan is the number of work units that are expected to be incurred when the
query is executed and its result produced. Please note that the query plan produced by a CBO is a
function of cost (prevailing computation load on the server), so plans may differ. We can make plans
stable by storing the plan outline.
Access Path - The access path represents the number of units of work done in accessing data from a
base table. The access path can be a table scan, a fast full index scan, or an index scan. During table
scan or fast full index scan, multiple blocks are read from the disk in a single I/O operation. Therefore,
the cost of a table scan or a fast full index scan depends on the number of blocks to scan and the
Page 29 of 54
29
multiblock read count value. The cost for an index scan depends on the levels in the B-tree, the number
of index leaf blocks to scan, and the number of rows to fetch using the rowid in the index keys. The
cost to fetch rows using rowids depends on the index-clustering factor. Although the clustering factor is
a property of the index, the clustering factor actually relates to the spread of similar indexed column
values within data blocks in the table. A lower clustering factor indicates that the individual rows are
concentrated within fewer blocks in the table. Conversely, a high clustering factor indicates that the
individual rows are scattered more randomly across blocks in the table. Therefore, a high clustering
factor means that it costs more to fetch rows by rowid using a range scan, because more blocks in the
table need to be visited to return the data.
2.3.5.2 Full Table Scans Vs Range Scans
Full table scans are cheaper than index range scans when accessing a large fraction of the blocks in the
table. This is because full table scans can use larger I/O calls, and fewer large I/O calls are cheaper than
many small I/O calls.
The elapsed time for an I/O call consists of two components:
o
o
In a typical I/O operation, setup costs consume most of the time. Data transfer time for an eight K buffer is
less than one ms (out of the total time of ten ms). This means that we can transfer 128KB in about 20 ms
with a single 128 KB call, opposed to 160 ms with 16 eight KB calls.
Example:
Suppose we are accessing 20% of the blocks of a 10,000 block table.
DB_FILE_MULTIBLOCK_READ_COUNT= 16
DB_BLOCK_SIZE=8k
Number of 8K I/O calls required for index access = 2,000(table) + index
Number of 128K I/O calls required for full table scan = 10,000/16 = 625
So, we observe that full table scan in this case is faster than index range scan.
Page 30 of 54
30
Explanation
This returns, at most, a single rowid. Oracle performs a unique scan if there is a
UNIQUEor a PRIMARYKEYconstraint that guarantees that the statement accesses
only a single row.
SELECTSTATEMENT
TABLEACCESSBYROWIDOFSO_HEADERS_ALL
INDEXUNIQUESCANOFSO_HEADERS_U2
Index unique scan is used when all columns of a unique (B-tree) index are specified
with equality conditions.
Index range scan is a common operation for accessing selective data. It can be bounded
(bounded on both sides) or unbounded (on one or both sides). Data is returned in the
ascending order of index columns. Multiple rows with identical
values are sorted in ascending order by the ROWIDs. If data is required to be sorted by
order, then we should use the ORDERBYclause, and do not rely on an index. If an
index can be used to satisfy an ORDERBYclause, then the optimizer uses this and
avoids a sort.
SELECTSTATEMENT
TABLEACCESSBYROWIDOFSO_HEADERS_ALL
INDEXRANGESCANOFSO_HEADERS_N5
The optimizer uses a range scan when the optimizer finds one or more leading columns
of an index in conditions, such as the following:
col1 = :b1
col1 < :b1
col1 > :b1
The condition col1 like %ASD does not result in a range scan. Range scans can
use unique or nonunique indexes. Range scans avoid sorting when index columns
constitute the ORDERBY/GROUPBYclause.
Index range scan descending is identical to index range scan, except that the data is
returned in a descending order. (Indexes, by default, are stored in ascending order.)
Usually, this is used when ordering data in a descending order to return the most recent
data first, or when seeking a value less than some value.
SELECTSTATEMENT
TABLEACCESSBYROWIDOFSO_HEADERS_ALL
INDEXRANGESCANDESCENDINGSO_HEADERS_U2
Page 31 of 54
31
The optimizer uses index range scan descending when an order by descending clause
can be satisfied by an index.
Index skip scans improve index scans by nonprefix columns. Often, it is faster to scan
index blocks than it is to scan table data blocks.
Skip scanning lets a composite index be logically split into smaller subindexes.
For example, table emp(sex, empno, address) with a composite index on (sex,
empno).
The number of logical subindexes is determined by the number of distinct values in the
initial column. Skip scanning is useful when the initial column of the composite index
is not specified in the query. In other words, it is "skipped."
Full Scans
This is available if a predicate references one of the columns in the index. The
predicate does not need to be an index driver. Full scan is also available when there is
no predicate, if all of the columns in the table referenced in the query are included in
the index and at least one of the index columns is not null. This can be used to
eliminate a sort operation, because the data is ordered by the index key. It reads the
blocks singly.
Fast full index scans are an alternative to a full table scan when the index contains all
the columns that are needed for the query, and at least one column in the index key has
the NOTNULLconstraint. Fast full scan accesses the data in the index itself,without
accessing the table. It cannot be used to eliminate a sort operation, because the data is
not ordered by the index key. It reads the entire index using multiblock reads (unlike a
full index scan) and can be parallelized.
Fast full scan is available only with the CBO. We can specify it with the initialization
parameter OPTIMIZER_FEATURES_ENABLEor the INDEX_FFShint.
Fast full index scans cannot be performed against bitmap indexes.
A fast full scan is faster than a normal full index scan in that it can use multiblock I/O
and can be parallelized just like a table scan. The following query and plan illustrate
this feature.
SELECTCOUNT(*)
FROMt1,t2
WHEREt1.c1>50
ANDt1.c2=t2.c1
Plan
SELECTSTATEMENT
SORTAGGREGATE
HASHJOIN
TABLEACCESSt1FULL
INDEXt2_c1_idxFASTFULLSCAN
Because index t2_c1_idx contains all columns needed from table t2, the
optimizer uses a fast full index scan on that index.
Page 32 of 54
32
Index Joins
This is a hash join of several indexes that together contain all the columns from the
table that are referenced in the query. If an index join is used, then no table access is
needed, because all the relevant column values can be retrieved from the indexes.
An index join cannot be used to eliminate a sort operation. Index join is available
only with the CBO.
The following statement uses an index join to access the empnoand salcolumns,
both of which are indexed, in the emptable:
SELECTempno,sal
FROMemp
WHEREsal>2000;
Plan
OPERATIONOPTIONSOBJECT_NAME
SELECTSTATEMENT
VIEWindex$_join$_001
HASHJOIN
INDEXRANGESCANEMP_SAL
INDEXFASTFULLSCANEMP_EMPNO
Bitmap Joins
This uses a bitmap for key values and a mapping function that converts each bit
position to a rowid. Bitmaps can efficiently merge indexes that correspond to several
conditions in a WHERE clause, using Boolean operations to resolve AND and OR
conditions.
Bitmap access is available only with the CBO (Oracle 9i + Enterprise Edition).
Join Type
Nested Loop Joins
Explanation
Nested loop (NL) joins are useful for joining small subsets of data and if the join
condition is an efficient way of accessing the second table.
It is very important to ensure that the inner table is driven from the outer table. If the
inner tables access path is independent of the outer table, then the same rows are
retrieved for every iteration of the outer loop. This can degrade performance
considerably. In such cases, hash joins joining the two independent row sources
perform better.
NESTEDLOOP
<OuterLoop>
<InnerLoop>
SELECTSTATEMENT
NESTEDLOOPS
TABLEACCESSBYINDEXROWIDSO_HEADERS_ALL
INDEXRANGESCANSO_HEADERS_N1
TABLEACCESSBYINDEXROWIDSO_LINES_ALL
INDEXRANGESCANSO_LINES_N1
Page 33 of 54
33
The optimizer uses NL joins when joining small number of rows with a good driving
condition between the two tables.
This operation is used when an outer join is used between two tables. The outer join
returns the outer (preserved) table rows, even when there are no corresponding rows in
the inner (optional) table.
In a regular outer join, the optimizer chooses the order of tables (driving and driven)
based on the cost. However, in an outer join, the order of tables is determined by the
join condition. The outer table (whose rows are being preserved) is used to drive to
The optimizer uses nested loop joins to process an outer join if the following are true:
o
o
Hash Joins
Hash joins are used for joining large data sets. The optimizer uses the smaller of the
two tables/data sources to build a hash table on the join key in memory. It then scans
the larger table, probing the hash table to find the joined rows.
This is best when the smaller table is small enough to fit in available memory. The cost
is then limited to a single read pass over the data for the two tables. However, if the
hash table grows too big to fit into the memory, then the optimizer breaks it up into
different partitions. As the partitions exceed allocated memory, parts are written to disk
to temporary segments.
After the hash table is complete:
o
o
o
Table 2 is scanned.
It is broken up into partitions like table 1.
Partitions are written to disk.
When the hash table build completes, it is possible that an entire hash table partition is
resident in memory. Then, we do not need to build the corresponding partition for the
second table. When table 2 is scanned, rows that hash to the resident hash table
partition can be joined and returned immediately.
Now, each hash table partition is read into memory:
o
o
This is repeated for the rest of the partitions. The cost can increase to two read passes
over the data and one write pass over the data. There is also the possibility that if the
hash table does not fit in the memory, then parts of it must be swapped in and out,
depending on the rows retrieved from the second table. Performance for this scenario
can be extremely poor.
Page 34 of 54
34
The optimizer uses a hash join to join two tables if they are joined using an equijoin
and if either of the following are true:
o
o
SELECTSTATEMENT
HASHJOIN
TABLEACCESSFULLSO_HEADERS_ALL
TABLEACCESSFULLSO_LINES_ALL
We can use the USE_HASH hint to advise the optimizer to use a hash join when
joining two tables together. We can investigate the values for the parameters
HASH_AREA_SIZE and HASH_JOIN_ENABLED if we are having trouble getting
the optimizer to use hash joins.
This operation is used for outer joins where the optimizer decides that the amount of
data is large enough to warrant an hash join, or it is unable to drive from the outer table
to the inner table.
Like an outer join, the order of tables is not determined by the cost, but by the join
condition. The outer table (whose rows are being preserved) is used to build the hash
table, and the inner table is used to probe the hash table.
SELECTSTATEMENT
FILTER
HASHJOINOUTER
TABLEACCESSBYINDEXROWIDRA_CUSTOMERS
INDEXRANGESCANRA_CUSTOMERS_N2
INDEXFASTFULLSCANSO_HEADERS_N1
The optimizer uses hash joins for processing an outer join if the data volume is high
enough to make hash join method efficient or if it is not possible to drive from the
outer table to inner table.
Sort merge joins can be used to join rows from two independent sources. Hash joins
generally perform better than sort merge joins. However, sort merge joins can perform
better than hash joins if the row sources are sorted already, and if a sort operation does
not have to be done.
However, if this involves choosing a slower access method (index scan vs. full table
scan), then the benefit of using a sort merge might be lost.
Sort merge joins are useful when the join condition between two tables is an inequality
condition (but not a nonequality) like <, <=, >, or >=. Sort merge joins perform better
than nested loop joins for large data sets. (We cannot use hash joins unless there is an
equality condition).
In a merge join, there is no concept of a driving table.
o
o
Both the inputs are sorted on the join key - sort join operation
The sorted lists are merged together - merge join operation
If the input is sorted already by the join column, then there is not a sort join operation
for that row source.
SELECTSTATEMENT
SORTGROUPBY
MERGEJOIN
Page 35 of 54
35
SORTJOIN
TABLEACCESSFULLSO_LINES_ALL
FILTER
SORTJOIN
TABLEACCESSFULLSO_LINES_ALL
The optimizer can choose sort merge join over hash join for joining large amounts of
data if any of the following are true:
o
o
o
o
We can use the USE_MERGEhint to advise the optimizer to use a merge join when
joining the two tables together.
The optimizer uses sort merge for an outer join if a nested loop join is inefficient. A
nested loop join can be inefficient because of data volumes, or because of sorts already
required by other operations, the optimizer finds it is cheaper to use a sort merge over a
hash join.
SELECTSTATEMENT
SORTGROUPBYNOSORT
MERGEJOINOUTER
SORTJOIN
INDEXFASTFULLSCANMTL_SYSTEM_ITEMS_U1
SORTJOIN
TABLEACCESSFULLSO_LINES_ALL
Cartesian Joins
A Cartesian join happens when one or more of the tables does not have any join
conditions to any other tables in the statement. The optimizer joins every row from one
data source with every row from the other data source (Cartesian product of the two
sets).
A full outer join acts like a combination of the left and right outer joins. In addition to
the inner join, rows from both tables that have not been returned in the result of the
inner join are preserved and extended with nulls. In other words, full outer joins let us
join tables together, yet still show rows which do not have corresponding rows in
tables joined-to.
Page 36 of 54
36
Table statistics
o
o
o
Column statistics
o
o
o
Index statistics
o
o
o
Number of rows
Number of blocks
Average row length
System statistics
Description
GATHER_INDEX_STATS
GATHER_TABLE_STATS
GATHER_SCHEMA_STATS
GATHER_DATABASE_STATS
GATHER_SYSTEM_STATS
DBMS_STATS.EXPORT_SCHEMA_STATS
DBMS_STATS.IMPORT_SCHEMA_STATS
Page 37 of 54
37
Page 38 of 54
38
If a SQL statement has a hint specifying an optimization approach and goal, then the optimizer uses the
specified approach regardless of the presence or absence of statistics, the value of the OPTIMIZER_MODE
initialization parameter, and the OPTIMIZER_MODE parameter of the ALTER SESSION statement.
Hint
ALL_ROWS
FIRST_ROWS(N)
Explanation
The ALL_ROWS hint explicitly chooses the cost-based approach to optimize a
statement block with a goal of best throughput (that is, minimum total resource
consumption).
The hints FIRST_ROWS( n) (where n is any positive integer) or FIRST_ROWS
instruct Oracle to optimize an individual SQL statement for fast response.
FIRST_ROWS(n) affords greater precision, because it instructs Oracle to choose the
plan that returns the first n rows most efficiently. The FIRST_ROWS hint, which
optimizes for the best plan to return the first single row, is retained for backward
compatibility and plan stability.
The optimizer ignores this hint in DELETE and UPDATE statement blocks
and in SELECTstatement blocks that contain any of the following syntax:
o
o
o
o
o
CHOOSE
The CHOOSE hint causes the optimizer to choose between the rule-based and costbased approaches for a SQL statement. The optimizer bases its selection on the presence
of statistics for the tables accessed by the statement. If the data dictionary has statistics
for at least one of these tables, then the optimizer uses the cost-based approach and
optimizes with the goal of best throughput. If the data dictionary does not have statistics
for these tables, then it uses the rule-based approach.
Explanation
The full hint explicitly chooses a full table scan.
FULL
select/*+FULL(pg)*/*fromtablepg
wherepg_postdate<'20041001'
ROWID
The ROWIDhint explicitly chooses a table scan by rowid for the specified table.
CLUSTER
The CLUSTER hint explicitly chooses a cluster scan to access the specified table. It
applies only to clustered objects.
Page 39 of 54
39
HASH
The HASHhint explicitly chooses a hash scan to access the specified table. It applies
only to tables stored in a cluster.
INDEX
The INDEXhint explicitly chooses an index scan for the specified table. We can use
the INDEXhint for domain, B-tree, bitmap, and bitmap join indexes. However,
Oracle recommends using INDEX_COMBINErather than INDEXfor bitmap indexes,
because it is a more versatile hint.
This hint can also optionally specify more than one indexes.
o
o
If this hint specifies a single available index, then the optimizer performs a scan on
this index. The optimizer does not consider a full table scan or a scan on another
index on the table.
If this hint specifies a list of available indexes, then the optimizer considers the
cost of a scan on each index in the list and then performs the index scan with the
lowest cost. The optimizer can also choose to scan multiple indexes from this list
and merge the results, if such an access path has the lowest cost. The optimizer
does not consider a full table scan or a scan on an index not listed in the hint.
If this hint specifies no indexes, then the optimizer considers the cost of a scan on
each available index on the table and then performs the index scan with the lowest
cost. The optimizer can also choose to scan multiple indexes and merge the results,
if such an access path has the lowest cost. The optimizer does not consider a full
table scan.
select/*+INDEX*/*fromtablepg
wherepg_postdate<='20010101'
INDEX_ASC
The INDEX_ASC hint explicitly chooses an index scan for the specified table. If the
statement uses an index range scan, then Oracle scans the index entries in ascending
order of their indexed values.
Because Oracles default behavior for a range scan is to scan index entries in ascending
order of their indexed values, this hint does not specify anything more than the INDEX
hint. However, we might want to use the INDEX_ASChint to specify ascending range
scans explicitly should the default behavior change.
INDEX_COMBINE
INDEX_JOIN
INDEX_DESC
INDEX_FFS
NO_INDEX
AND_EQUAL
The INDEX_COMBINEhint explicitly chooses a bitmap access path for the table. If no
indexes are given as arguments for the INDEX_COMBINEhint, then the optimizer uses
whatever Boolean combination of bitmap indexes has the best-cost estimate for the
table. If certain indexes are given as arguments, then the optimizer tries to use some
Boolean combination of those particular bitmap indexes.
The INDEX_JOIN hint explicitly instructs the optimizer to use an index join as an
access path. For the hint to have a positive effect, a sufficiently small number of indexes
must exist that contain all the columns required to resolve the query.
The INDEX_DESChint explicitly chooses an index scan for the specified table. If the
statement uses an index range scan, then Oracle scans the index entries in descending
order of their indexed values. In a partitioned index, the results are in descending order
within each partition.
The INDEX_FFShint causes a fast full index scan to be performed rather than a full
table scan.
The NO_INDEXhint explicitly disallows a set of indexes for the specified table.
The AND_EQUAL hint explicitly chooses an execution plan that uses an access path
that merges the scans on several single-column indexes.
select/*+AND_EQUAL(pgTABLE_IDX1TABLE_IDX8)*/*fromtable
Page 40 of 54
40
pg
wherepg_postdate<='20010101'
Explanation
The USE_CONCAThint forces combined ORconditions in the WHEREclause
of a query to be transformed into a compound query using the UNIONALLset
operator.
Generally, this transformation occurs only if the cost of the query using the
concatenations is cheaper than the cost without them.
The USE_CONCAT hint turns off IN-list processing and OR-expands all
disjunctions, including IN-lists.
NO_EXPAND
REWRITE
NOREWRITE
MERGE
The NO_EXPANDhint prevents the cost-based optimizer from considering ORexpansion for queries having ORconditions or IN-lists in the WHEREclause.
Usually, the optimizer considers using ORexpansion and uses this method if it
decides that the cost is lower than not using it.
The REWRITEhint forces the cost-based optimizer to rewrite a query in terms
of materialized views, when possible, without cost consideration. We can use the
REWRITE hint with or without a view list. With a view list, Oracle uses that
view regardless of its cost.
The NOREWRITEhint disables query rewrite for the query block, overriding the
setting of the parameter QUERY_REWRITE_ENABLED.
The MERGE hint allows us to merge a view on a per-query basis. If a view's
query contains a GROUPBYclause or DISTINCToperator in the SELECT
list, then the optimizer can merge the view's query into the accessing statement
only if complex view merging is enabled.
Complex merging can also be used to merge an INsubquery into the accessing
statement if the subquery is uncorrelated.
Complex merging is not cost-based--that is, the accessing query block must
include the MERGEhint.
NO_MERGE
STAR_TRANSFORMATION
Page 41 of 54
41
Even if the hint is given, there is no guarantee that the transformation will take
place. The optimizer only generates the subqueries if it seems reasonable to do
so. If no subqueries are generated, then there is no transformed query, and the
best plan for the untransformed query is used, regardless of the hint. This hint
will override whatever the value is in STAR_TRANSFORMATION_ENABLED
initialization parameter.
The FACThint is used in the context of the star transformation to indicate to the
transformation that the hinted table should be considered as a fact table.
FACT
NO_FACT
Explanation
The ORDERED hint causes Oracle to join tables in the order in which they
appear in the FROM clause. If we omit the ORDERED hint from a SQL
statement performing a join, then the optimizer chooses the order in which to
join the tables.
We might want to use the ORDEREDhint to specify a join order as we are more
likely to know something about the number of rows selected from each table that
the optimizer does not. This can allow us to choose an inner and outer table
better than the optimizer could.
The statement joins table TAB1to table TAB2and then joins the result to table
TAB3:
SELECT/*+ORDERED*/tab1.col1,tab2.col2,tab3.col3
FROMtab1,tab2,tab3
WHEREtab1.col1=tab2.col1
ANDtab2.col1=tab3.col1
STAR
The STARhint forces a star query plan to be used, if possible. A star plan has
the largest table in the query last in the join order and joins it with a nested loops
join on a concatenated index. The STAR hint applies when there are at least
three tables, the large tables concatenated index has at least three columns, and
there are no conflicting access or join method hints. The optimizer also considers
different permutations of the small tables.
Page 42 of 54
42
Use of the USE_NLand USE_MERGEhints is recommended with the ORDEREDhint. Oracle uses these
hints when the referenced table is forced to be the inner table of a join, and they are ignored if the
referenced table is the outer table.
Hint
USE_NL
Explanation
The USE_NL hint causes Oracle to join each specified table to another row
source with a nested loops join using the specified table as the inner table.
SELECT/*+ORDEREDUSE_NL(customers)*/
accounts.balance,customers.last_name,customers.first_name
FROMaccounts,customers
WHEREaccounts.custno=customers.custno
USE_MERGE
Here, customers table is the inner table for nested loops operation.
The USE_MERGEhint causes Oracle to join each specified table with another
row source with a sort-merge join.
SELECT/*+USE_MERGE(empdept)*/*
FROMemp,dept
WHEREemp.deptno=dept.deptno
USE_HASH
The USE_HASH hint causes Oracle to join each specified table with another
row source with a hash join.
SELECT/*+use_hash(empdept)*/*
FROMemp,dept
WHEREemp.deptno=dept.deptno
DRIVING_SITE
If this query is executed without the hint, then rows from deptare sent to the
local site, and the join is executed there. With the hint, the rows from empare
sent to the remote site, and the query is executed there, returning the result to the
local site. This hint is useful if we are using distributed query optimization.
LEADING
The LEADINGhint causes Oracle to use the specified table as the first table in
the join order. If we specify two or more LEADING hints on different tables,
then all of them are ignored. If we specify the ORDEREDhint, then it overrides
all LEADINGhints.
Page 43 of 54
43
WHEREexists(SELECT/*+HASH_SJ*/*
FROMemp
WHEREemp.deptno=dept.deptno
ANDsal>200000)
Explanation
The PARALLEL hint allows us to specify the desired number of concurrent
servers that can be used for a parallel operation. The hint applies to the INSERT,
UPDATE, and DELETE portions of a statement as well as to the table scan
portion. If any parallel restrictions are violated, the hint is ignored.
SELECT/*+FULL(po)PARALLEL(po,5)*/*
FROMtablepo
NOPARALLEL
PQ_DISTRIBUTE
PARALLEL_INDEX
NOPARALLEL_INDEX
Page 44 of 54
44
NOAPPEND
CACHE
Explanation
The APPEND hint allows us to enable direct-path INSERT.In direct-path
INSERT, data is appended to the end of the table, rather than using existing
space currently allocated to the table. In addition, direct-path INSERT
bypasses the buffer cache and ignores integrity constraints. As a result, directpath INSERTcan be considerably faster than conventional INSERT.
The NOAPPEND hint enables conventional INSERT by disabling parallel
mode for the duration of the INSERT statement. (Conventional INSERT is
the default in serial mode, and direct-path INSERT is the default in parallel
mode).
The CACHEhint specifies that the blocks retrieved for the table are placed at
the most recently used end of the LRU list in the buffer cache when a full table
scan is performed. This option is useful for small lookup tables.
SELECT/*+FULL(po)CACHE(po)*/*
FROMtablepo
NOCACHE
The NOCACHE hint specifies that the blocks retrieved for the table are placed
at the least recently used end of the LRU list in the buffer cache when a full
table scan is performed. This is the normal behavior of blocks in the buffer
cache.
SELECT/*+FULL(po)NOCACHE(po)*/*
FROMtablepo
UNNEST
NO_UNNEST
PUSH_PRED
NO_PUSH_PRED
Page 45 of 54
45
PUSH_SUBQ
CURSOR_SHARING_EXACT
Note:
The CACHEand NOCACHEhints affect system statistics "table scans(long tables)" and "table scans(short tables)", as
shown in the V$SYSSTATview.
REFERENCES
Link
notes
at
Page 46 of 54
46
Page 47 of 54
47
APPENDIX A
Appendix A.1 PMServer Configuration File
CommThreadPoolSize=30
ServiceThreadPoolSize=30
EngineThreadPoolSize=30
LMRepoConnPoolSize=60 /*To support 60 concurrent repository connections */
# Absolute or relative path of the file where the LM will write its messages.
LogFileName=/path/<Rep Name>/pmserver.log
drive */
# Determine one of the two server data movement modes: UNICODE or ASCII.
# If not specified, ASCII data movement mode is assumed.
DataMovementMode=ASCII /* Unless we are processing multiple languages, ASCII mode
is ok from performance perspective */
# Maximum number of sessions Based on our peak time requirement. Set it 20% over
the maximum concurrency requirement to account for processing first time failures.
MaxSessions=200
# Load Manager (pmserver) shared memory, in bytes
# For each 10-count increase of MaxSessions, increase this by 2000000 bytes
LMSharedMem=40000000
# Obsolete parameter PMCacheDir: PowerMart Cache directory location
# Will be de-supported in future release
# Recommendation: Use server variable $PMCacheDir in the Workflow Manager
PMCacheDir=/tmp /* Should be high speed swap space rather than mounted drive to
improve paging efficiency */
# Applies if there is no free LMSHM slot available to run a session. If set
# to Yes, it fails the session else it places the session in the pending queue.
FailSessionIfMaxSessionsReached=No
# Specify Yes to turn on PowerMart 4.0 / PowerCenter 1.0 date handling
# compatibility.
DateHandling40Compatibility=No
# 3X compatability overrides AggregateTreatNullAsZero to one and
# AggregateTreatRowAsInsert to one.
Pmserver3XCompatability=0
# If this flag is set SUM(X) with all values X = NULL will return zero.
# Otherwise SUM(X) will return NULL.
AggregateTreatNullAsZero=0
Page 48 of 54
48
#
#
#
#
Aggregator widget will treat all row types to be add to list of groups from
the grouping perspective for a datadriven session with nonincremental
aggregation. If not set, then row type delete will be removed from the
list of groups.
AggregateTreatRowAsInsert=0
# Let pmserver know which display format to display Date/Time in
# e.g. DateDisplayFormat=YYYY/MM/DD HH24:MI:SS
DateDisplayFormat=DY MON DD HH24:MI:SS YYYY
TreatNullInComparisonOperatorsAs=
# Enable debugging capabilities of this server
LoadManagerAllowDebugging=Yes
# Create indicator files for file output
CreateIndicatorFiles=No
# Max # of DB connections to be used by Lookup/SP.
# 0 means unlimited
MaxLookupSPDBConnections=0
# Max # of internal DB connections that can be used by
# the application.
# The default (and minimum value) is 100
MaxSybaseConnections=100
MaxMSSQLConnections=100
# Number of deadlock retries that will be attempted per partition.
NumOfDeadlockRetries=10
# Number of seconds to sleep before attempting next deadlock retry
DeadlockSleep=0
#
#
#
#
#
#
SybaseIQLocalToPmServer=No
#
#
#
#
XMLWarnDupRows=Yes
Page 49 of 54
49
OutputMetaDataForFF=
# Whether to validate codepage compatibility between source/server/target/lkup/SP
ValidateDataCodePages=Yes
# Output session log in UTF8 format
SessionLogInUTF8=No
DB_BLOCK_BUFFER_STATS
select name, value
from v$sysstat
where name in ('consistent gets', 'db block gets', 'physical reads')
LIB_STATS
select sum (pins) pins, sum (reloads) reloads
from v$librarycache
DATA_DICT_CACHE
select sum(gets) GETS, sum(getmisses) GETMISSES
from v$rowcache
SORT_STATS
select name, value
from v$sysstat
where name like 'sort%'
ROLLBACK_STATS
Page 50 of 54
50
LATCH_STATS
select name, gets, misses, sleeps, immediate_gets, immediate_misses
from v$latch
where name in ('redo allocation', 'redo copy')
REDO_SPACE_REQ
select name, value
from v$sysstat
where name = 'redo log space requests'
HitRatio=1(physicalreads/(consistentgets+dbblockgets))
Page 51 of 54
51
Logicalreads=dbblockgets+consistentgets
Or
'HitRatio=(logicalreadsphysicalreads)/logicalreads'
Suggestion
If the hit ratio is less than 60%70%, increase the initialization
parameterDB_BLOCK_BUFFERS. ** NOTE: Increasingthisparameterwill
increasetheSGAsize.
Page 52 of 54
52
select db_name,
DATA_DICT_CACHE
run_seq,
run_date,
sum_gets,
sum_misses
from
select*fromdfile_statswheredb_name='GGLDWP2'{orGGLDWP1}
STATS 5- Rollback Contention
GETS#ofgetsontherollbacksegmentheader
WAITS#ofwaitsfortherollbacksegmentheader
selectdb_name,run_seq,run_date,(sum(waits)/sum(gets))*100asRatio
fromrollback_stats
wheredb_name='GGLDWP2'{GGLDWP1}
groupbydb_name,run_seq,run_date
If the ratio of waits to gets is more than 1% or 2%, we may consider creating more rollback segments.
STATS 6- Redo Log Contention
The table REDO_SPACE_REQ holds information for how often the user processes had to wait for space in
the redo log buffer.
select*fromREDO_SPACE_REQ
This value should be near 0. If this value increments consistently, processes have had to wait for space in
the redo buffer. If this condition exists over time, we can possibly, increase the size of LOG_BUFFER in
the init.ora file in increments of 5% until the value nears 0.
NOTE: increasing the LOG_BUFFER value will increase total SGA size.
STATS 7- Latch Contention
GETS - # of successful willing-to-wait requests for a latch
MISSES - # of times an initial willing-to-wait request was unsuccessful
IMMEDIATE_GETS - # of successful immediate requests for each latch
IMMEDIATE_MISSES = # of unsuccessful immediate requests for each latch
SLEEPS - # of times a process waited and requests a latch after an initial willing-to-wait request
Page 53 of 54
53
If the latch requested with a willing-to-wait request is not available, the requesting process waits a short
time and requests again. If the latch requested with an immediate request is not available, the requesting
process does not wait, but continues processing.
selectdb_name,run_seq,run_date,gets,misses,sleeps,immediate_gets,
immediate_missesfromlatch_stats
If either ratio exceeds 1%, performance will be affected. Decreasing the size of
LOG_SMALL_ENTRY_MAX_SIZE reduces the number of processes copying information on the redo
allocation latch. Increasing the size of LOG_SIMULTANEOUS_COPIES will reduce contention
for redo copy latches.
STATS 8: Checking for fragmented Data objects (Index and Data Table Spaces)
Physical reads and writes to fragmented table spaces result in additional rotational latency delays at the disk
drive. This delay becomes pronounced especially in case of large volume reads and writes to the database.
Our databases (GGLDWP1 and GGLDWP2) happen to share this operational characteristics of large
volume reads and writes.
IfnumberofextentsisapproachingMaxextents,itistimetodefragment
thetable.
TABLEFragmentation
selecta.owner,segment_name,segment_type,
sum(bytes),max_extents,count(*)
fromdba_extentsa,dba_tablesb
wheresegment_name=b.table_name
havingcount(*)>3
groupbya.owner,segment_name,segment_type,max_extents
orderbya.owner,segment_name,segment_type,max_extents
INDEXFRAGMENTATION
selecta.owner,segment_name,segment_type,
sum(bytes),max_extents,count(*)
fromdba_extentsa,dba_indexesb
wheresegment_name=index_name
havingcount(*)>3
groupbya.owner,segment_name,segment_type,max_extents
orderbya.owner,segment_name,segment_type,max_extents
Page 54 of 54
54