The document discusses various measures to improve back-end, front-end, and data model performance in Informatica and databases. For back-end performance, it recommends avoiding certain transformations like joiners and aggregators when possible, using indexes and transferring filters to source qualifiers. For databases, it suggests using clusters, partitioning, parallelism, and dynamic tuning. For front-end performance, it recommends indexes, aggregate tables, and dimensional modeling with global dimensions and translation tables.

1. Back-End Performance Improvement Measures
The following transformations in Informatica should be
avoided to the maximum possible extent :
1) Joiners : Joiners are typically needed for
heterogeneous sources (say flat files and
database tables). In such cases it is
preferable to split the mapping in 2
mappings, the first one loading data from
flat file to intermediate table and the next
one using this intermediate table and the
original database table. To make
it more efficient, indexes should be used.
2) Aggregators : Use database group by function
instead of aggregator .
3) Routers : This can be avoided based on functionality of
mappings.
4) Filters : The filter condition can sometimes be transferred
to
Source Qualifier SQL depending upon functionality
of mapping.

2. Back-End Performance Improvement Measures
5) Lookups : Whenever only one port is the output
of any lookup then it should be made unconnected
lookup and then called from the transformation
(typically expression) conditionally. If such lookups
are of reusable nature, then the same object can be
used in many mappings/mapplets and thus the
maintenance of such lookups becomes much easier
(this way we achieve better performance plus better
development environment) .
6) Explain Plan : Every SQL generated in the source qualifier
should go through the explain plan utility provided
by Oracle to ensure the most efficient execution plan
(or at least to ensure that indexes are being used
wherever required and in case indexes don’t exist
then the same needs to be created).
7) Session Properties : There are lots of session properties which
can be modified to ensure better read and write
throughput.

3. Database Performance Improvement Measures
1) Clusters : The usage of clusters improves the performance because the related
set of data is kept together.
2) Partitioning : Partitioning of tables is known to improve the performance.
3) Parallelism : Parallel Query option when set improves the performance.
4) Dynamic Tuning : The database can be tuned dynamically from time to time
by the DBA’s depending upon the data warehouse status
as of any point in time.

4. Front-End Performance Improvement Measures
1) Indexes : Introduction of additional indexes wherever applicable can improve
the performance of reports.
2) Aggregate Tables : At times the reports are based on fact tables which
contains huge volume of data. If the group by
operations
like sum,max,avg etc. are computed on this set of records
it would be time consuming. Introduction of aggregate
table in the data model would be of immense use because
then the whole computation logic would be shifted to
back-end and thus the reports based on this aggregate table
would be faster. In the front end universe, we can provide
the drill down facility moving down from aggregate table
to the original fact table.

5. Data Model Improvement Measures
1) Functionality : The functionality of the data model can be checked to
ensure that it serves the whole reporting requirement in
efficient way.
2) Global Dimensions : The global dimensions should be used wherever
possible. In case the data coming from source doesn’t
conform with that present in the global dimensions (say
for example, different codes referring to the same
country),
then there should be translation tables to take care of it.

6. Data Model Improvement Measures
1) Functionality : The functionality of the data model can be checked to
ensure that it serves the whole reporting requirement in
efficient way.
2) Global Dimensions : The global dimensions should be used wherever
possible. In case the data coming from source doesn’t
conform with that present in the global dimensions (say
for example, different codes referring to the same
country),
then there should be translation tables to take care of it.