Analize table ... estimate statistics

I have read in this discussion group that it was a good idea to analyze the spatial index table to optimize performance.
Should this be done:
- only once?
- after loading the layer?
- each time it is massively updated?
BTW what does "sample 32 percent" mean?
Thanks,
Jean-Pierre

Hi Jean-Pierre,
I've never had to run this more than once (after the spatial index was created on an initial data set), but I don't do a lot of updates usually.
There are two ways to analyze a table:
analyze table table_name compute statistics;
analyze table table_name estimate statistics sample N percent; --- where N is an integer
Sometimes I have index tables with millions and millions of rows. If I run compute statistics is can take an hour or more. If I say estimate statistics sample 1 percent it completes in seconds/minutes and all of the right things happen with respect to performance. I use sample so I can work with data faster. BTW - this is only for quadtree indexes. It doesn't hurt to gather stats on an rtree index table, but it doesn't help either.
The procedure I posted happens to sample about 32 percent of the rows, but there is nothing magical about this number.

Similar Messages

What is analize table for?

I know it has something to be about statisc or something like that (I am sure now I must look as someone that has no idea about Oracle)
so... what is analize table exactly for? does it improve the index or something like that after calcullating how many rows has a table and stuff like that?

Hi,
Since Oracle 8i the Cost Based Optimizer (CBO) is the preferred optimizer for Oracle.
In order to make good use of the CBO, you need to create statistics for the data in the database. There are several options to create statistics. From Oracle 8i the DBMS_STATS package is the preferred method Oracle. The ANALYZE command is available for all versions of Oracle, however to obtain faster and better statistics use the procedures supplied in 8i and above DBMS_STATS.GATHER_SCHEMA_STATS:
e.g: ANALYZE table tableName computee.g: EXEC DBMS_STATS.gather_table_stats('SCOTT', 'EMPLOYEES');
Cheers

What is Estimate Statistics ?

Hi everybody,
I wanna know what is analyzing the table ... ???
What is estimate statistics ... ???
How they contribute to performance ... ???

hi
kindly check this out
http://www.oracle-base.com/articles/8i/CostBasedOptimizerAndDatabaseStatistics.php
and why they are used for .....its the information about the table ,indexes we get from it ...and how they are analyzed or not...frequently we can see it ........
CHeers

SQL Developer Behavior When Gathering Table/Index Statistics

Hey All,
Not sure if this has been posted yet. I did a search and did not find any threads on the topic though.
I noticed with SQL Developer 2.x, when you using the context menu to gather table/index statistics for a given table, you get no modal progress/waiting window like you did in 1.x. It just kind of "does nothing", even though it did actually execute the DBMS_STATS package. If you press cancel and try to navigate around, you get multiple "Connection is Busy" errors. Eventually it will come back and say "Statistics gathered for table <whatever>". In the old versions there was just a modal window with an animated progress bar while it ran the DBMS_STATS package. What happened to that? Or is this something unique to my install? Anyone else ran into this? Is there a fix or somewhere I can report this as an official bug? FWIW I'm running 2.1.1.64, and this did occur in the initial 2.0 release.
It is very confusing the first time you run into it... I pressed the "apply" button several times thinking it didn't take, but it ended up running the DBMS_STATS for every click I did.
Thanks!

Same happens to all the other context menu opened dialogs. Indeed very confusing at first and disturbing.
The only official site to report bugs is Metalink/MOS, but you might be lucky if someone from the team picks it up here.
Regards,
K.

New table without statistics returns invalid number of rows

Hi,
I've been searching for a while now for an explanation for the following "problem"
We have an Oracle 11.1.0.7 database on AIX5.3
In this database we have two tables, called KRT_PRODUCTS_INFO and KRT_STRUCTURES_INFO ( the table name don't really matter ).
The scenario is as following:
If we recreate these tables like:
CREATE TABLE KRT_PRODUCT_INFO_BUP AS SELECT * FROM KRT_PRODUCT_INFO;
DROP TABLE KRT_PRODUCT_INFO CASCADE CONSTRAINTS;
CREATE TABLE KRT_PRODUCT_INFO (...) TABLESPACE PIM_DATA NOLOGGING NOCOMPRESS NOCACHE NOPARALLEL MONITORING;
CREATE INDEX KRT_PRODUCT_INFO_X1 ON KRT_PRODUCT_INFO (PRODUCT_NUMBER) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
CREATE INDEX KRT_PRODUCT_INFO_X2 ON KRT_PRODUCT_INFO (PIM_ARTICLEREVISIONID) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
INSERT INTO KRT_PRODUCT_INFO (SELECT * FROM KRT_PRODUCT_INFO_BUP);
COMMIT;
CREATE TABLE KRT_STRUCTURE_INFO_BUP AS SELECT * FROM KRT_STRUCTURE_INFO;
DROP TABLE KRT_STRUCTURE_INFO CASCADE CONSTRAINTS;
CREATE TABLE KRT_STRUCTURE_INFO (...) TABLESPACE PIM_DATA NOLOGGING NOCOMPRESS NOCACHE NOPARALLEL MONITORING;
CREATE INDEX KRT_STRUCTURES_X1 ON KRT_STRUCTURE_INFO (STRUCTURE_GRP_REV_ID) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
CREATE INDEX KRT_STRUCTURES_X2 ON KRT_STRUCTURE_INFO (STRUCTURE_GRP_IDENTIFIER) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
CREATE INDEX KRT_STRUCTURES_X3 ON KRT_STRUCTURE_INFO (STRUCTURE_GRP_ID) NOLOGGING TABLESPACE PIM_DATA NOPARALLEL;
INSERT INTO KRT_STRUCTURE_INFO (SELECT * FROM KRT_STRUCTURE_INFO_BUP);
COMMIT;
and we run a complex query with these two tables, this query only return a couple of rows ( exactly 24 !!! )
If we however generate statistics on these tables after creation, the correct number of rows is returned, being 1.167.991 rows
The statistics are gathered using:
BEGIN
SYS.DBMS_STATS.GATHER_TABLE_STATS (
OwnName => 'PIM_KRG'
,TabName => 'KRT_PRODUCT_INFO'
,Estimate_Percent => NULL
,Method_Opt => 'FOR ALL COLUMNS SIZE REPEAT '
,Degree => NULL
,Cascade => TRUE
,No_Invalidate => FALSE);
END;
BEGIN
SYS.DBMS_STATS.GATHER_TABLE_STATS (
OwnName => 'PIM_KRG'
,TabName => 'KRT_STRUCTURE_INFO'
,Estimate_Percent => NULL
,Method_Opt => 'FOR ALL COLUMNS SIZE REPEAT '
,Degree => NULL
,Cascade => TRUE
,No_Invalidate => FALSE);
END;
/I can imagine that the 'plan' for the query used is wrong because of missing statistics.
But I can't imagine that it would actually return an incorrect number of rows.
I tested this behaviour in Toad and sqlplus ( first thought it was Toad ), and both behave the same.
Another fact is, that the "problem" is NOT reproducable on our TEST environment, that runs on Oracle 11.1.0.7 on Windows2008
Just to be sure this is the "complex" query used. It is not developed by me, and I think it looks somewhat strange but that shouldn't matter:
SELECT sr."Identifier" STRUCTURE_IDENTIFIER
, ar_i."Identifier" ITEM_NUMBER
, SUM (REPLACE (NVL (s.HIDE_LE10, 0) + NVL (p.HIDE_LE10, 0), 2, 1))
hide_le10
, SUM (REPLACE (NVL (s.HIDE_LE30, 0) + NVL (p.HIDE_LE30, 0), 2, 1))
hide_le30
, SUM (REPLACE (NVL (s.HIDE_LE40, 0) + NVL (p.HIDE_LE40, 0), 2, 1))
hide_le40
, SUM (REPLACE (NVL (s.HIDE_LE50, 0) + NVL (p.HIDE_LE50, 0), 2, 1))
hide_le50
, SUM (REPLACE (NVL (s.HIDE_LE55, 0) + NVL (p.HIDE_LE55, 0), 2, 1))
hide_le55
, SUM (REPLACE (NVL (s.HIDE_LE60, 0) + NVL (p.HIDE_LE60, 0), 2, 1))
hide_le60
, SUM (REPLACE (NVL (s.HIDE_LE70, 0) + NVL (p.HIDE_LE70, 0), 2, 1))
hide_le70
, SUM (REPLACE (NVL (s.HIDE_LE75, 0) + NVL (p.HIDE_LE75, 0), 2, 1))
hide_le75
, SUM (REPLACE (NVL (s.HIDE_LE58, 0) + NVL (p.HIDE_LE58, 0), 2, 1))
hide_le58
, SUM (REPLACE (NVL (s.HIDE_LE80, 0) + NVL (p.HIDE_LE80, 0), 2, 1))
hide_le80
, SUM (REPLACE (NVL (s.HIDE_LE90, 0) + NVL (p.HIDE_LE90, 0), 2, 1))
hide_le90
, SUM (REPLACE (NVL (s.HIDE_LE92, 0) + NVL (p.HIDE_LE92, 0), 2, 1))
hide_le92
, SUM (REPLACE (NVL (s.HIDE_LE94, 0) + NVL (p.HIDE_LE94, 0), 2, 1))
hide_le94
, SUM (REPLACE (NVL (s.HIDE_LE96, 0) + NVL (p.HIDE_LE96, 0), 2, 1))
hide_le96
, COUNT (*) cnt
FROM KRAMP_HPM_MAIN."StructureRevision" sr
, KRAMP_HPM_MAIN."StructureGroupRevision" sgr
, KRAMP_HPM_MASTER."ArticleStructureMap" asm
, KRAMP_HPM_MASTER."ArticleRevision" ar_p
, KRAMP_HPM_MASTER."ArticleDetail" ad_p
, KRAMP_HPM_MASTER."ArticleRevision" ar_i
, KRAMP_HPM_MASTER."ArticleDetail" ad_i
, KRAMP_HPM_MASTER."ArticleReference" ar
, KRT_STRUCTURE_INFO s
, KRT_PRODUCT_INFO p
WHERE sr."StructureID" = sgr."StructureID"
AND sgr."StructureGroupID" = asm."StructureGroupID"
AND ar_p."ID" = asm."ArticleRevisionID"
AND ar_p."ID" = ad_p."ArticleRevisionID"
AND ad_p."Res_Text100_02" = 'PRODUCT'
AND ar_i."ID" = ad_i."ArticleRevisionID"
AND ad_i."Res_Text100_02" = 'ARTICLE'
AND ar."ArticleRevisionID" = ar_p."ID"
AND ar."ReferencedSupplierAID" = ar_i."Identifier"
AND s.STRUCTURE_GRP_REV_ID = sgr."ID"
AND p.PIM_ARTICLEREVISIONID = ar_p."ID"
GROUP BY sr."Identifier", ar_i."Identifier";Any ideas are welcome..
Thanks
FJFranken

Hemant K Chitale wrote:
These two tables are in the PIM_KRG schema while the other tables in the query are distributed across two other schemas "KRAMP_HPM_MAIN" and "KRAMP_HPM_MASTER" ?
Do you happen to have the same table names occurring in multiple schemas - the query is then referencing the data in the wrong schema ?
Hemant K ChitaleHi,
This is not the case. The KRAMP_HPM schema's are application dedicated schema's
And this also then does not explain why the results are correct after generating statistics.
Anyway thanks for the tip.
FJFranken

SAP database tables - Column statistics not found for table in DB02 - During import, inconsistent tables were found - Some open conversion requests still exist in the ABAP dictionary.

Hi Experts,
I'm implementing SAP note 1990492 which requires manual implementation. Implementation includes modifying standard tables (i.e. append
the structure FIEU_S_APP_H to table FIEUD_FIDOC_H). After this I've adjusted the table in SE14 (Database Utility). I've done checks in SE14 and it shows the table is consistent.
But during DB02 -> Space folder -> Single table analysis -> Input table name -> Indexes tab -> Upon clicking statistics, there is a warning "Column statistics not found for table".
Our basis team is implementing an Add-On in the development system related to RWD Context Sensitive Help. They cannot proceed due to the following inconsistencies found in the table.
Screenshot error from the activity:
Screenshot from DB02:
I'm an ABAP developer and have no other ideas on what to do. Thanks in Advanced.

Hi All,
We were able to fix the issue through the following:
1. Call transaction
SE14.
2. Enter the name of
the table and choose "Edit".
3. Choose
"Indexes".
4. Select the index
and choose "Choose (F2)".
5. If you choose
"Activate and adjust", the system creates the index again and it is
consistent.
6. Check the object
log of this activation.
7. If an error
occurs, eliminate the cause and reactivate the index.

Gathering table only statistics with DBMS_SCHEDULER

Version:10gR2
I have statistics gathering sql file called gather_emp_stats.sql whose contents are as follows
begin
dbms_stats.gather_table_stats('SCOTT', 'EMP',
estimate_percent=>100,
no_invalidate=>FALSE,
degree => DBMS_STATS.DEFAULT_DEGREE,
cascade=>TRUE);
end;How can i run the above .sql script every five minutes using DBMS_SCHEDULER?
begin
dbms_scheduler.create_job(
      job_name => 'gather_emp_statistics'
     ,job_type => 'PLSQL_BLOCK'
     ,job_action => '??----??'
     ,start_date => sysdate
     ,repeat_interval => 'FREQ=MINUTELY;INTERVAL=5'
     ,enabled => TRUE
     ,comments => 'Gathering stats for EMP table.');
end;

If you don't insist of using a file (I think scheduler can do files too, but I don't know the syntax currently).
Simply put the command in one line and use it as parameter
begin
dbms_scheduler.create_job(
      job_name => 'gather_emp_statistics'
     ,job_type => 'PLSQL_BLOCK'
     ,job_action => 'dbms_stats.gather_table_stats(''SCOTT'', ''EMP'', estimate_percent=>100, no_invalidate=>FALSE, degree => DBMS_STATS.DEFAULT_DEGREE, cascade=>TRUE);'
     ,start_date => sysdate
     ,repeat_interval => 'FREQ=MINUTELY;INTERVAL=5'
     ,enabled => TRUE
     ,comments => 'Gathering stats for EMP table.');
end;
/

How to find table/index statistics are outdated

Hi guys,
How can we find whether the statistics of a table or a index are outdated.
thanks...

You can use DBA_TAB_MODIFICATIONS view: please read "Determining Stale Statistics" http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/stats.htm#PFGRF94738

LTAP Table Update Statistics Problem

Hi ,
We are facing misaligned in update statics for LTAP table. Threshold values has been assigned to this is 50% .So as per threshold value assigned , the cahnges happening in number of inserted row and changed in row are more in number (when it exceed its threshold value). My problem is that can we change the threshold value in less % ,so that changes happening in inserted now and coloum will be in low in number.IS it possible, then how and what will be impact of other table or system . Is it possbile or it is recomended to do this task.Please help me in this with details that how and what can i do better in this.
Regards
Brijesh Prasad

Brijesh,
Did you try DB20?
Manoj

Rebuild Table

Table where lots of deletion or insertion takes place , probably has High HWM. If the HWM is high , it is better to rebuild table segment for performance sake.
my question is when to rebuild a table/index and how to find that a table has High water mark?
please revert me with the answer.

hi
to find high water mark ...
here it is .......
There is no single system table which contains the high water mark (HWM) for a table. A table's HWM can be calculated using the results from the following SQL statements:
SELECT BLOCKS
FROM DBA_SEGMENTS
WHERE OWNER=UPPER(owner) AND SEGMENT_NAME = UPPER(table);
ANALYZE TABLE owner.table ESTIMATE STATISTICS;
SELECT EMPTY_BLOCKS
FROM DBA_TABLES
WHERE OWNER=UPPER(owner) AND TABLE_NAME = UPPER(table);
Thus, the tables' HWM = (query result 1) - (query result 2) - 1
NOTE: You can also use the DBMS_SPACE package and calculate the HWM = TOTAL_BLOCKS - UNUSED_BLOCKS - 1.
and if the index rebuild...
http://www.quest-pipelines.com/newsletter-v2/rebuild.htm
hope this helps
CHeers

How to use indexes correctly in oracle

Hi guys
on one table i have indexes on 3 columns in the following order
a
b
c
When i m writing a select statement in my where clause what should be the order? like
where
a='some value' and
b='some value' and
c='some value';
or in reverse order like this
c='some value' and
b='some value' and
a='some value';
please let me know.
Thanks

If you have an index on a,b,c the difference in performance can be on the index order.
If column "a" has only 2 unique values then the sub values of the index only has 50% of the remaining values, the cost optimizer on Oracle will probably skip the index as an index scan of 50% is slower than a full table scan.
If a has 100 unique values then the remaining search is only on 1% of the values so is likely to be used.
As with any optimisation try using
explain plan for selec x,y,z from a_table
from where
a='some value' and
b='some value' and
c='some value'
If the index is not being used firstly try
analyze table estimate statistics
sample 10 percent
for all indexes
for all indexed columns;
and failing than try different orders in acceptance environment.

Oracle 9 table statistics doesn't work

Hy to everybody.
Hy have a query on 3 big tables (10 millions of rows for each one).
i perform always the statistics of these 3 tables with
ANALYZE table TABLE1 estimate statistics sample 1 percent;
but if i make the select statement without hint, it takes 20 minutes.
If i put the hints of full
select /* FULL (TABLE1) FULL(TABLE2) FULL(TABLE3) */+
it takes 2 minutes.
Why oracle can't understand that is better to not use indexes to perform this query, but i have to tell him to go in full?
Thanks in advance!

user13012184 wrote:
Why oracle can't understand that is better to not use indexes to perform this query, but i have to tell him to go in full?Probably because you are using the wrong command to gather statistics.
http://download.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_46a.htm#SQLRF01105
Oracle Corporation strongly recommends that you use the DBMS_STATS package rather than ANALYZE to collect optimizer statistics. That package lets you collect statistics in parallel, collect global statistics for partitioned objects, and fine tune your statistics collection in other ways. Further, the cost-based optimizer, which depends upon statistics, will eventually use only statistics that have been collected by DBMS_STATS. See Oracle9i Supplied PL/SQL Packages and Types Reference for more information on this package.

Gathering statistics on interMedia indexes and tables

Has anyone found any differences (like which one is better or worse) between using the ANALYZE sql command, dbms_utility package, or dbms_stats package to compute or estimate statistics for interMedia text indexes and tables for 8.1.6? I've read the documentation on the subject, but it is still unclear as to which method should be used. The interMedia text docs say the ANALYZE command should be used, and the dbms_stats docs say that dbms_stats should be used.
Any help or past experience will be grateful.
Thanks,
jj

According to the Support Document "Using statistics with Oracle Text" (Doc ID 139979.1), no:
Q. Should we gather statistics on the underlying DR$/DR# tables? If yes/no, why?
A. The recommendation is NO. All internal recursive queries have hints to fix the plans that are deemed most optimal. We have seen in the past that statistics on the underlying DR$ tables may cause query plan changes leading to serious query performance problems.
Q. Should we gather statistics on Text domain indexes ( in our example above, BOOKS_INDEX)? Does it have any effect?
A: As documented in the reference manual, gathering statistics on Text domain index will help CBO to estimate selectivity and costs for processing a CONTAINS() predicate. If the Text index does not have statistics collected, default selectivity and cost will be used.
So 'No' on the DR$ tables and indexes, 'yes' on the user table being indexed.

Help,why brconnect do not collect statistics for mseg table?

I found "MSEG" table`s statistics is too old.
so i check logs in db13,and the schedule job do not collect statistics for "MSEG".
Then i execute manually: brconnect -c -u system/system -f stats -t mseg -p 4
this command still do not collect for mseg.
KS1DSDB1:oraprd 2> brconnect -c -u system/system -f stats -t mseg u2013f collect -p 4
BR0801I BRCONNECT 7.00 (46)
BR0154E Unexpected option value 'u2013f' found at position 8
BR0154E Unexpected option value 'collect' found at position 9
BR0806I End of BRCONNECT processing: ceenwjre.log 2010-11-12 08.41.38
BR0280I BRCONNECT time stamp: 2010-11-12 08.41.38
BR0804I BRCONNECT terminated with errors
KS1DSDB1:oraprd 3> brconnect -c -u system/system -f stats -t mseg -p 4
BR0801I BRCONNECT 7.00 (46)
BR0805I Start of BRCONNECT processing: ceenwjse.sta 2010-11-12 08.42.04
BR0484I BRCONNECT log file: /oracle/PRD/sapcheck/ceenwjse.sta
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.11
BR0813I Schema owners found in database PRD: SAPPRD*, SAPPRDSHD+
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.12
BR0807I Name of database instance: PRD
BR0808I BRCONNECT action ID: ceenwjse
BR0809I BRCONNECT function ID: sta
BR0810I BRCONNECT function: stats
BR0812I Database objects for processing: MSEG
BR0851I Number of tables with missing statistics: 0
BR0852I Number of tables to delete statistics: 0
BR0854I Number of tables to collect statistics without checking: 0
BR0855I Number of indexes with missing statistics: 0
BR0856I Number of indexes to delete statistics: 0
BR0857I Number of indexes to collect statistics: 0
BR0853I Number of tables to check (and collect if needed) statistics: 1
Owner SAPPRD: 1
MSEG
BR0846I Number of threads that will be started in parallel to the main thread: 4
BR0126I Unattended mode active - no operator confirmation required
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.16
BR0817I Number of monitored/modified tables in schema of owner SAPPRD: 1/1
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.16
BR0877I Checking and collecting table and index statistics...
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.16
BR0879I Statistics checked for 1 table
BR0878I Number of tables selected to collect statistics after check: 0
BR0880I Statistics collected for 0/0 tables/indexes
BR0806I End of BRCONNECT processing: ceenwjse.sta 2010-11-12 08.42.16
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.17
BR0802I BRCONNECT completed successfully
the log says:
Number of tables selected to collect statistics after check: 0
Could you give some advices? thanks a lot.

Hello,
If you would like to force the creation of that stats for table MSEG you need to use the -f (force) switch.
If you leave out the -f switch the parameter from stats_change_threshold is taken like you said correctly:
[http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/02/0ae0c6395911d5992200508b6b8b11/content.htm|http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/02/0ae0c6395911d5992200508b6b8b11/content.htm]
[http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/cb/f1e33a5bd8e934e10000000a114084/content.htm|http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/cb/f1e33a5bd8e934e10000000a114084/content.htm]
You have tried to do this in your second example :
==> brconnect -c -u system/system -f stats -t mseg u2013f collect -p 4
Therefore you received:
BR0154E Unexpected option value 'u2013f' found at position 8
BR0154E Unexpected option value 'collect' found at position 9
This is the correct statement, however the hyphen in front of the f switch is not correct.
Try again with the following statement (-f in stead of u2013f) you will see that it will work:
==> brconnect -c -u system/system -f stats -t mseg -f collect -p 4
I hope this can help you.
Regards.
Wim

Statistics Analysis on Tables that are often empty

Right now I'm dealing with a user application that was originally developed in Ora10g. Recently the database was upgraded to Ora11g, and the schema and data was imported successfully.
However, since the user started using Ora11, some of their applications have been running slower and slower. I'm just wondering if the problem could be due to statistics.
The application has several tables which contains temporary data. Usually these tables are empty, although when a user application runs they are populated, and queried against, and then at the end the data is deleted. (Its this program that's running slower and slower.)
I'm just wondering if the problem could be due to a problem with user statistics.
When I look at the 'last_analyzed' field in user_tables, the date goes back to the date of last import. I know Oracle regularly updates statistics, so what I suspect is happening is that, by luck, Oracle has only been gathering statistics when the tables are empty. (And since the tables are empty, the statistics are of no help in optimizing the DB.)
Am I on the right track?
And if so, is there a way to automatically trigger a statistics gather job when a table gets above a certain size?
System details:
Oracle: 11gR2 (64 bit) Standard version
File System: ASM (GRID infrastructure)

Usually these tables are empty, although when a user application runs they are populated, and queried against, and then at the end the data is deletedYou have three options (and depending on how the data changes, you might find that not all temporary tables work best with the same option) :
1. Load representative data into the temporary table, collect statistics (including any histograms that you identify as necessary) and then lock the statistics
2. Modify the job to re-gather statistics immediately after a temporary table is populated
3. Delete statistics and then lock the statistics and check the results (execution plan and performance) when the optimizer uses dynamic sampling
Note : It is perfectly reasonable to create indexes on temporary tables -- provided that you DO create the correct indexes. If jobs are querying the temporary tables for the full data set (all rows) indexes are a hindrance. If there are many separate queries against the temporary table, each query retrieiving a small set of rows, an index or two may be beneficiial. Also some designs do use unique indexes to enforce uniqueness when the tables are loaded.
Hemant K Chitale

Analize table ... estimate statistics

Similar Messages

Maybe you are looking for