1. We used bulk load to our stage stable from MV and then rebuild the index. In this process we used to do Analyze table and gather stat.[The optimizer mode must be set to 'cost' not 'rule' to run the analyze command]
Sometimes we have changes for the tables, for example if we have regular ETL process that constantly modifies the database structure or table contents. The statistics that Oracle collects from the last table analyzation might be out of sync with the current data dictionary. And this information is often used by the optimizer when querying. Therefore querys base against the old statistics would run slow and the database performance could be decreased because of the changed statistic not being collected accordingly.
Oracle will collect statistic on the number of rows, the number of empty data blocks, the number of blocks below the high water mark, the average data block free space, the average row length, and the number of chained rows in a table when the Oracle ANALYZE TABLE command is performed.Oracle ANALYZE TABLE can be used to collect statistics on a specific table.
select 'Analyze Table '||table_name||' compute statistics;' from user_tables;
select 'Analyze Index '||index_name||' compute statistics;' from user_indexes;
2. Alter session to set parallel.
A DML statement can be parallelized only if you have explicitly enabled parallel DML in the session or in the SQL statement. To enable this mode in a session, run the following SQL statement:
ALTER SESSION ENABLE PARALLEL DML;
To enable parallel DML mode in a specific SQL statement, include the ENABLE_PARALLEL_DML SQL hint. For example:
INSERT /*+ ENABLE_PARALLEL_DML */ …
This mode is required because parallel DML and serial DML have different locking, transaction, and disk space requirements and parallel DML is disabled for a session by default.
To check the parallel processing status of your session, use the following query:
SELECT username, pq_status, pdml_status, pddl_status
FROM v$session
WHERE sid = sys_context('userenv','sid');
With SQL hints:
SELECT /*+ PARALLEL (16) */ …
The degree specified in the hint overrides the degree defined for the table or set in an ALTER SESSION statement.
If a degree number is not specified, then the degree defined for the table is used unless it is 1 (noparallel). Then the default degree is used.
SELECT /*+ PARALLEL */ …
You can also specify which table to use parallel processing on.
SELECT /*+ PARALLEL( TABLE1, 16 ) */
The hint syntax also works without the comma. In this case, the blank character works as a separator.
SELECT /*+ PARALLEL( TABLE1 16 ) */ …
If you don’t specify a table name, then parallel processing is used to read all the tables in the query.
You can also specify parallel processing for indexes.
SELECT /*+ PARALLEL_INDEX( TABLE1, 16 ) */ …
SELECT /*+ PARALLEL_INDEX( TABLE1 16 ) */ …
In this case, parallel processes will be used to read any indexes on table1, but will not be used to read table1 itself. Including an index name in the hint further restricts parallel processing to just that index.
SELECT /*+ PARALLEL_INDEX( TABLE1, INDEX2, 16 ) */ …
SELECT /*+ PARALLEL_INDEX( TABLE1 INDEX2 16 ) */ …
Hints can be used with query blocks if the SQL statement has sub-queries. For more information on hints, see the Oracle SQL Language Reference, chapter 3 on “Basic Elements of Oracle SQL”, section on comments. In the hint, do not prefix the table or index name with the schema name as this will not work. The SQL statement will run successfully, no error message will be displayed, but the hint will not work and parallel processes will not be used. This is standard hint behavior.
3. Flash bufferring.
We are keeping the reference tables and typecode tables in the Flash Cache since they are the most frequently used tables for our joining. We can also use keep buffer pool but that will store it in Ram instead of Hard Disk.
-- Force EMP to remain in the Smart Flash Cache, space provided.
ALTER TABLE scott.emp STORAGE (FLASH_CACHE KEEP);
-- Reset EMP to default use of Smart Flash Cache.
ALTER TABLE scott.emp STORAGE (FLASH_CACHE);
ALTER TABLE scott.emp STORAGE (FLASH_CACHE DEFAULT);
Or
alter table emp storage (buffer_pool keep)
--> script for displaying flash_cache waits:
SELECT
name,
value
FROM
v$sysstat
WHERE
name IN
('physical read flash cache hits',
'physical reads',
'consistent gets',
'db block gets',
'flash cache inserts');
--> see flash_cache entries in the data buffers with the v$bh view, where the stats starts with flash:
select
owner||'.'||object_name
from
v$bh, dba_objects
where
v$bh.status like ('flash%');
Factors that we have used to optimize query response:-
collection of table statistics
memory allocation
parallelism