Column Order of index on 12M record table

I have table name
tablea
Fields
kickoff_id int
and
status int
and many others.....
Now tablea contain 12M records.
I have query
Select * from
tablea
where
status =2 and kickoff_id > 0
status can have three possible values 0,1,2
and
kickoff_id can have 0 to 8 values....
I am planning to make an index on status and kickoff_id
So what should be preferrable order of index...
status,kickoff_id
or
kickoff_id and status
Regards
Mahesh

I would think the column which restricts the number of rows to a greater extent should come first.
also, here is someting from Oracle documentation that may help you decide on type of index that will be better suited for
your requirement.
===============================================================================================================
Cardinality
The advantages of using bitmap indexes are greatest for low cardinality columns: that is, columns in which the number of distinct values is small compared to the number of rows in the table. If the number of distinct values of a column is less than 1% of the number of rows in the table, or if the values in a column are repeated more than 100 times, then the column is a candidate for a bitmap index. Even columns with a lower number of repetitions and thus higher cardinality can be candidates if they tend to be involved in complex conditions in the WHERE clauses of queries.
For example, on a table with 1 million rows, a column with 10,000 distinct values is a candidate for a bitmap index. A bitmap index on this column can out-perform a B-tree index, particularly when this column is often queried in conjunction with other columns.
B-tree indexes are most effective for high-cardinality data: that is, data with many possible values, such as CUSTOMER_NAME or PHONE_NUMBER. In some situations, a B-tree index can be larger than the indexed data. Used appropriately, bitmap indexes can be significantly smaller than a corresponding B-tree index.
In ad hoc queries and similar situations, bitmap indexes can dramatically improve query performance. AND and OR conditions in the WHERE clause of a query can be quickly resolved by performing the corresponding Boolean operations directly on the bitmaps before converting the resulting bitmap to rowids. If the resulting number of rows is small, the query can be answered very quickly without resorting to a full table scan of the table.
=============================================================================================================================
I have table name
tablea
Fields
kickoff_id int
and
status int
and many others.....
Now tablea contain 12M records.
I have query
Select * from
tablea
where
status =2 and kickoff_id > 0
status can have three possible values 0,1,2
and
kickoff_id can have 0 to 8 values....
I am planning to make an index on status and kickoff_id
So what should be preferrable order of index...
status,kickoff_id
or
kickoff_id and status
Regards
Mahesh

Similar Messages

Table Column Ordering Matters when using Forms6i

Just an FYI on something strange that we encountered...
We have a Forms application that calls a function within a Package stored in the database. The only parameter to the function is a PL/SQL record that is based on the columns of a table. Our users need to run the application against 2 different database instances. We receve an "ORA-04062: Signature of Package has changed" error message when running the Form against the database that we DID NOT compile the form against. The reason is because the column ordering of the table that the record is based upon is different between the 2 databases.
Here are the details:
Setup:
     2 different databases. ( devDB and prdDB )
     1 table:
          On devDB:
               create table test_file (file_id NUMBER,
description VARCHAR2(256)
          Same table on prdDB but with different column ordering:
               create table test_file (description VARCHAR2(256),
file_id NUMBER
     1 database package in both databases:
CREATE OR REPLACE PACKAGE PS_TEST AS
     SUBTYPE tr_file IS TEST_FILE%ROWTYPE;
     FUNCTION Create_File( r_file     tr_file ) RETURN NUMBER;
END PS_TEST;
     1 Oracle Form that fills the tr_file record with data and calls PS_TEST.Create_File passing in the tr_file record.
Results:
     If the above Form is compiled on the database devDB, trying to run the Forms Executable against prdDB will generate an error message stating: ORA-04062: Signature of Package has changed. If the above Forms executable is run against devDB, everything works fine. The problem is that when the Oracle form is compiled it apparently captures the tr_file signature from the package, which would be something like ( file_id, description ) on devDB since it is specified as %ROWTYPE. When this compiled form is ran against the prdDB database, the package signature is different because the tr_file signature would be something like ( description, file_id ) on prdDB because of the column ordering. The error doesn't occur if you recreate the "devDB" table with the columns in the same order as "prdDB". This would only be a problem with using the %ROWTYPE with PL/SQL records.
So it appears that column ordering does matter in some situations.
Thanks.

would create a cell renderer only once -- the same
JTextPane is used to render any cell in the table that
shares the same renderer.Thanks for the reply. It's something I'm going to look into, but I do create only one renderer, and use that one renderer to create new JTextPane subclasses when getCellRendererComponent() is called - hence, there is one renderer, but there are multiple instances of the actual rendered component.
In the meantime, I'm just marking up the text with HTML to create the presentation I want, and it works okay. It'd be nice if I can get it working with Styles, though.
Thanks again,
- Chris

Index Key Column Order

I've several queries running on a table (for fetching data), to improve the performance of these queries, we've an Index in place, however, the query optimizer suggests upto 94% cost reduction possibility because of the order of the Index key columns in
40% of the queries.
I know that if I create an Index that matches the order of columns, the result will be better. However, I would like to know is there a possibility of changing order of columns in query itself so that it can use the existing Index? (I tried it but didn't
make any difference).
Also, I want to know how does SQL Server decides a key column order for any query?

Reordering the predicates in your query will not help.
If your query has exact matches on all columns in the index, then the order of the columns in the index key doesn't matter.
For example:
CREATE TABLE t
(col1 char(5)
,col2 char(5)
,description varchar(200)
CREATE INDEX ix ON t (col1, col2)
SELECT description
FROM t
WHERE col1 = 'abc'
AND col2 = 'def'
However, if not all index key columns are filtered, or they are not filtered with equality, then the order does matter.
For example:
SELECT description
FROM t
WHERE col1 LIKE 'a%'
AND col2 = 'def'
In the query above, an index on (col2, col1) is more effective than an index on (col1, col2). If col1 is the leading column, the first match (and every next match) of "col2 = 'def'" has to be scanned within the results of "col1 LIKE 'a%'".
If col2 is the leading column, then no col2 keys with the unmatched values have to be skipped. In other words, fewer keys have to be scanned.
Maybe your query selects a range of values of the index's leading column...
Gert-Jan

Retrieve the Purchase Order Condition Records Table

Hallo!
I have found this code right here:
http://www.sap-basis-abap.com/sapab025.htm
It is very useful particular for purposes which I need. Please can somebody
try to fix the error to get it working. There is an internal table missing.
Regards
Ilhan
Retrieve the Purchase Order Condition Records Table
select * from ekko.
       select * from konv where knumv = ekko-knumv
           "Get all the condition records for the purchase order
       endselect.
endselect.
* Get the info record conditions record
* First declare the record structure for the key
data: begin of int_konp,
             txt1(5),
             lifnr(5),
             matnr(18),
             txt2(4),
             txt3(1),
        end of int_konp.
clear: konh, konp, int_konp.
* data for the record key konh-vakey
int_konp-txt1    = '00000'.
int_konp-lifnr    = ekko-lifnr+5(5).
int_konp-matnr = ekpo-matnr(18).
int_konp-txt2    = 'ALL'.
int_konp-werks = ekpo-werks.
int_konp-txt3    = '0'.
select * from konh where      kschl = 'PB00'            "Conditions (Header)
                                     and datab => p_datum.       "valid from date
      if konh-vakey = int_konp.                                  "Conditions (Item)
             select single * from konp where knumh = konh-knumh.
             continue.
      endif.
endselect.

Hi flora
Just get through the sequence .
see the table fields ...
1. From EKKO table take an entry which is having pricing conditions.
Now in the fields list check out for field EKKO-KNUMV(document condition number).
2.Take this condition number and now goto table KONV.
Give the document condition number in the field KONV-KNUMV and execute .
This will lead to a list of document condition numbers and some other fields .
3.Now check for field KONV-KNUMH ,KONV-KAWRT(quantity) and note the value KONV-KWERT .
(Remember this is at header level).
This is ur condition record number.
**comments
Now from document condition number we got the condition record number (KNUMH).
4. now since u want the item level tax procedure go to table KONP and give the condition record number and execute .
This will give u a list of details .
Now concentrate on KONV-KAWRT (scale quantity) KONP-KBETR(rate) as this table will store Pricing per UNIT so product of these two will give u the total pricing tax, for a particular condition type say PR00 .
For that particular condition item .
Check the pricing procedure .
See t-code VK13 and check the pricing procedure .
From me23 check the same PO num select the item and check the pricing conditions applicable .
Select a particular pricing and goto condition->analysis->analysis pricing ,
Better take help of a SD functional consultant in the process.
regards,
vijay.

Column Order in a pivot table

Hi,
I have a question about the column order in a Pivot Table in a WebI (xi r3.1) report
At the moment I have the following Pivot Table
                   |1                                                 | 2
                   | Produced Water | Produced Oil | Produced Water | Produced Oil
Platform 1   | 2                         | 3                    | 4                         | 5
Platform 2   | 3                         | 4                    | 5                         | 6
I want to have the following pivot table instead
                    | Produced Water                         | Produced Oil
                    | 1                         | 2                    | 1                         | 2
Platform 1    | 2                         | 4                    | 3                         | 5
Platform 2    | 3                         | 5                    | 4                         | 6
Is it possible to setup the above pivot table in a WebI report?
Many Thanks for any help,
Dirk Jan

Dirk Jan,
That's a question regurlarly asked to me by users and the solution (as long as nobody is comming up with a better one) is to create variables for the measures for each month (using the WHERE operator).
So you need to define 12 variables (for each month) for Product Oil and Product Water (PO month1, PO month 2, ...., PW month 1, PW month 2 ....) using the formula (eg. PO month1):
=[Product Oil] Where ([month] = 1)
Then instead of a crosstab you build a table where you can put the variables in any order you want.
Regards,
Harry

Schema Design for 10^6+ rows table (Indicator Column / Bitmap Join Index?)

Hi all,
I read following suggestion for a SELECT with LEFT OUTER JOIN in a DB2 consulting company paper for a 10 million-rows table:
SELECT columns
FROM ACCTS A LEFT JOIN OPT1 O1
ON      A.ACCT_NO = O1.ACCT_NO
AND     A.FLAG1 = ‘Y’
LEFT JOIN OPT2 O2
ON      A.ACCT_NO = O2.ACCT_NO
AND     A.FLAG2 = ‘Y’
WHERE A.ACCT_NO = 1
For DB2, according to the paper, the following is true: Iff A.FLAG1 <> ‘Y’ Then no Table or Index Access on OPT1 is done. Same for A.FLAG2/OPT2.
I recreated the situation for ORACLE with the following script and came to some really interesting questions
DROP TABLE maintbl CASCADE CONSTRAINTS;
DROP TABLE opt1 CASCADE CONSTRAINTS;
DROP TABLE opt2 CASCADE CONSTRAINTS;
CREATE TABLE maintbl
id INTEGER NOT NULL,
dat VARCHAR2 (2000 CHAR),
opt1 CHAR (1),
opt2 CHAR (1),
CONSTRAINT CK_maintbl_opt1 CHECK(opt1 IN ('Y', 'N')) INITIALLY IMMEDIATE ENABLE VALIDATE,
CONSTRAINT CK_maintbl_opt2 CHECK(opt2 IN ('Y', 'N')) INITIALLY IMMEDIATE ENABLE VALIDATE,
CONSTRAINT PK_maintbl PRIMARY KEY(id)
CREATE TABLE opt1
maintbl_id INTEGER NOT NULL,
adddat1 VARCHAR2 (100 CHAR),
adddat2 VARCHAR2 (100 CHAR),
CONSTRAINT PK_opt1 PRIMARY KEY(maintbl_id),
CONSTRAINT FK_opt1_maintbltable FOREIGN KEY(maintbl_id) REFERENCES maintbl(id)
CREATE TABLE opt2
maintbl_id INTEGER NOT NULL,
adddat1 VARCHAR2 (100 CHAR),
adddat2 VARCHAR2 (100 CHAR),
CONSTRAINT PK_opt2 PRIMARY KEY(maintbl_id),
CONSTRAINT FK_opt2_maintbltable FOREIGN KEY(maintbl_id) REFERENCES maintbl(id)
INSERT ALL
WHEN 1 = 1 THEN
INTO maintbl (ID, opt1, opt2, dat) VALUES (nr, is_even, is_odd, maintbldat)
WHEN is_even = 'N' THEN
INTO opt1 (maintbl_id, adddat1, adddat2) VALUES (nr, adddat1, adddat2)
WHEN is_even = 'Y' THEN
INTO opt2 (maintbl_ID, adddat1, adddat2) VALUES (nr, ADDdat1, ADDdat2)
SELECT LEVEL AS NR,
CASE WHEN MOD(LEVEL, 2) = 0 THEN 'Y' ELSE 'N' END AS is_even,
CASE WHEN MOD(LEVEL, 2) = 1 THEN 'Y' ELSE 'N' END AS is_odd,
TO_CHAR(DBMS_RANDOM.RANDOM) AS maintbldat,
TO_CHAR(DBMS_RANDOM.RANDOM) AS adddat1,
TO_CHAR(DBMS_RANDOM.RANDOM) AS adddat2
FROM DUAL
CONNECT BY LEVEL <= 100;
COMMIT;
SELECT * FROM maintbl
LEFT OUTER JOIN opt1 ON maintbl.id = opt1.maintbl_id AND maintbl.opt1 = 'Y'
LEFT OUTER JOIN opt2 ON maintbl.id = opt2.maintbl_id AND maintbl.opt2 = 'Y'
WHERE id = 1;
Explain plan for "Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi":
http://i.imgur.com/f0AiA.png
As one can see, the DB uses a view to index-access the opt tables iff indicator column maintbl.opt1='Y' in the main table.
Explain plan for "Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production":
http://i.imgur.com/iKfj8.png
As one can see, the DB does NOT use the view, instead uses a pretty useless case-statement
Now my questions:
1) What does the optimizer do in 11.2 XE?!?
2) In General: Do you suggest this table-setup? Does your yes/no suggestion depend on the rowcount in the tables? Of course I see the problem with incorrectly updated columns and would NEVER do it if there is another truly relational solution with same performance possibly.
3) Is there a way to avoid performance issues if I don't use an indicator column in ORACLE? Is this what a [Bitmap Join Index|http://docs.oracle.com/cd/E11882_01/server.112/e25789/indexiot.htm#autoId14] is for?
Thanks in advance and happy discussing,
Blama

Fair enough. I've included a cut-down set of SQL below.
CREATE TABLE DIMENSION_DATE
DATE_ID NUMBER,
CALENDAR_DATE DATE,
CONSTRAINT DATE_ID
PRIMARY KEY
(DATE_ID)
CREATE UNIQUE INDEX DATE_I1 ON DIMENSION_DATE
(CALENDAR_DATE, DATE_ID);
CREATE TABLE ORDER_F
ORDER_ID VARCHAR2(40 BYTE),
SUBMITTEDDATE_FK NUMBER,
COMPLETEDDATE_FK NUMBER,
-- Then I add the first bitmap index, which works:
CREATE BITMAP INDEX SUBMITTEDDATE_FK ON ORDER_F
(DIMENSION_DATE.DATE_ID)
FROM ORDER_F, DIMENSION_DATE
WHERE ORDER_F.SUBMITTEDDATE_FK = DIMENSION_DATE.DATE_ID;
-- Then attempt the next one:
CREATE BITMAP INDEX completeddate_fk
ON ORDER_F(b.date_id)
FROM ORDER_F, DIMENSION_DATE b
WHERE ORDER_F.completeddate_fk = b.date_id;
-- which results in:
-- ORA-01408: such column list already indexed

Estimate index size on a table column before creating it

Hi
Is it possible to estimate the size of the index before actually creating it on a table column.
I tried the below query. It gives size of the index after creating it.
SELECT (SUM(bytes)/1048576)/1024 Gigs, segment_name
FROM user_extents
WHERE segment_name = 'IDX_NAME'
GROUP BY segment_name.
Can anyone through some light which system table will give this information.

You can get an approximation by estimating the number of rows to be indexes, the average column lengths of the columns in the index, and the overheads for an index entry - once you have some reasonable stats on the table.
I wrote a piece of code to demonstrate the method a few years ago - it's got some errors, but I've highlighted them in an update to the note: http://www.jlcomp.demon.co.uk/index_efficiency_2.html
Regards
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

BUG: Jdev 11.1.1.0.0 -- DB table data export column order is not preserved

Hello,
I've ran into a problem with Jdeveloper 11g, public release, Build JDEVADF_MAIN.BOXER_GENERIC_081002.2127.5156. Oracle IDE version is 11.1.1.0.31.51.56
When I connect to Oracle database, get the table list, right click on the table and select 'Export Data'->csv. The dialog box opens with three tabs: Format, Columns, Where. The column order displayed in both tabs Columns and Where is alphabetic. Because alphabetic ordering re-arranges columns from their initial ordering in the table, this screws up the export because columns are not in their intended order. This same problem occurs when I try to export data from views to generate a CSV file with a particular column order for our vendor. Since Jdev scrambles the column order I have to rely on SQLdeveloper to generate CSV exports, since SQLdeveloper has the same functionality but it preserves the column order.
It would be nice if Jdeveloper preserved the column order on export.
Thanks!

Update:
This bug is now also present in the SQL Developer 1.5.3.
I've posted a bug report on the appropriate forum: BUG: SQL Developer 1.5.3 CSV export column order broken

Selecting Records from 125 million record table to insert into smaller table

Oracle 11g
I have a large table of 125 million records - t3_universe. This table never gets updated or altered once loaded, but holds data that we receive from a lead company.
I need to select records from this large table that fit certain demographic criteria and insert those into a smaller table - T3_Leads - that will be updated with regard to when the lead is mailed and for other relevant information.
My question is what is the best (fastest) approach to select records from this 125 million record table to insert into the smaller table. I have tried a variety of things - views, materialized views, direct insert into smaller table...I think I am probably missing other approaches.
My current attempt has been to create a View using the query that selects the records as shown below. Then use a second query that inserts into T3_Leads from this View V_Market. This is very slow. Can I just use an Insert Into T3_Leads with this query - it did not seem to work with the WITH clause?    My Index on the large table is t3_universe_composite and includes zip_code, address_key, household_key.
CREATE VIEW V_Market as
WITH got_pairs    AS
     SELECT /*+ INDEX_FFS(t3_universe t3_universe_composite) */ l.zip_code, l.zip_plus_4, l.p1_givenname, l.surname, l.address, l.city, l.state, l.household_key, l.hh_type as l_hh_type, l.address_key, l.narrowband_income, l.p1_ms, l.p1_gender, l.p1_exact_age, l.p1_personkey, e.hh_type as filler_data, 1.p1_seq_no, l.p2_seq_no
     ,      ROW_NUMBER () OVER ( PARTITION BY l.address_key
                                  ORDER BY      l.hh_verification_date DESC
                  ) AS r_num
     FROM   t3_universe e
     JOIN   t3_universe l ON
            l.address_key = e.address_key
            AND l.zip_code = e.zip_code
          AND   l.p1_gender != e.p1_gender
             AND   l.household_key != e.household_key
             AND l.hh_verification_date >= e.hh_verification_date
SELECT *
FROM got_pairs
where l_hh_type !=1 and l_hh_type !=2 and filler_data != 1 and filler_data != 2 and zip_code in (select * from M_mansfield_02048) and p1_exact_age BETWEEN 25 and 70 and narrowband_income >= '8' and r_num = 1
Then
INSERT INTO T3_leads(zip, zip4, firstname, lastname, address, city, state, household_key, hh_type, address_key, income, relationship_status, gender, age, person_key, filler_data, p1_seq_no, p2_seq_no)
select zip_code, zip_plus_4, p1_givenname, surname, address, city, state, household_key, l_hh_type, address_key, narrowband_income, p1_ms, p1_gender, p1_exact_age, p1_personkey, filler_data, p1_seq_no, p2_seq_no
from V_Market;

I had no trouble creating the view exactly as you posted it. However, be careful here:
and zip_code in (select * from M_mansfield_02048)
You should name the column explicitly rather than select *. (do you really have separate tables for different zip codes?)
About the performance, it's hard to tell because you haven't posted anything we can use, like explain plans or traces but simply encapsulating your query into a view is not likely to make it any faster.
Depending on the size of the subset of rows you're selecting, the /*+ INDEX hint may be doing your more harm than good.

Select * columns order

Is it possible, that "SELECT *" returns records, where columns are
ordered in a different order, than the order they were
positioned/specified when table was created?
For example, lets assume that table T contains columns c1,c2,..c10.
Can this be possible, that the * (asterisk) shows the columns in a
different orderm the c1 and c10 changed their position for example:
query:
"SELECT * FROM T"
results:
c10, c2, c3, .., c9, c1.
I think you anderstood my question now.
The sql-standard doesn't tell about it nothing, but i have heard that
"selesct *" can produce columns in a random order in some situations.
Notice, that i'm not talking about "ORDER"-operator. I have heard that if one make a table with plenty of columns and adds plenty of indexes and constraints to the columns, then "select *" really will produce mistery column order.
Thank you for answering,
Regards.

FWIW I suspect that block structure is not a factor either.
Consider
SQL> CREATE VIEW v AS SELECT * FROM emp;
View created.
SQL> desc emp
Name                          Null?    Type
EMPNO                         NOT NULL NUMBER(4)
ENAME                                  VARCHAR2(10)
JOB                                    VARCHAR2(9)
MGR                                    NUMBER(4)
HIREDATE                               DATE
SAL                                    NUMBER(7,2)
COMM                                   NUMBER(7,2)
DEPTNO                                 NUMBER(2)
SQL> desc v
Name                          Null?    Type
EMPNO                         NOT NULL NUMBER(4)
ENAME                                  VARCHAR2(10)
JOB                                    VARCHAR2(9)
MGR                                    NUMBER(4)
HIREDATE                               DATE
SAL                                    NUMBER(7,2)
COMM                                   NUMBER(7,2)
DEPTNO                                 NUMBER(2)
SQL> WITH accounting_emp AS (SELECT * FROM v WHERE deptno = 10)
2     , accounting_dept AS (SELECT * FROM dept WHERE deptno = 10)
3 SELECT *
4 FROM   ( SELECT * FROM accounting_dept )
5*      , ( SELECT * FROM accounting_emp );
DEPTNO DNAME          LOC           EMPNO ENAME      JOB         MGR HIREDATE    SAL COMM DEPTNO
    10 ACCOUNTING     NEW YORK       7782 CLARK      MANAGER    7839 09-JUN-81 2450           10
    10 ACCOUNTING     NEW YORK       7839 KING       PRESIDENT       17-NOV-81 5000           10
    10 ACCOUNTING     NEW YORK       7934 MILLER     CLERK      7782 23-JAN-82 1300           10
3 rows selected.This returns rows in a consistent (if apparently undocumented) order, which seems to be something like:
* Tables/views in FROM list
* SELECT list
* SELECT list within views in FROM list
* SELECT list of subquery factoring clause
* ALL_TAB_COLUMNS.COLUMN_ID (for tables and views)
* ALL_TYPE_ATTRS.ATTR_NO for attributes of object types
If it did not, it would break many valid PL/SQL constructions as others have mentioned, including %ROWTYPE , UPDATE ... SET ROW, INSERT ... VALUES [record], and INSERT without column list. This type of failure will be familiar to those developing invoker rights packages, since the table found at runtime could have columns in a different order than the one compiled against, which will produce effects such as values appearing in the wrong attributes of %ROWTYPE records.

INDEX on VIEW or TABLE when using CONTAINS function on the VIEW

Hi,
I'm querying a view with a contains function and I'm getting an error:
query: select * from view where contains(name,'jack OR jill')>0
ORA-20000: Oracle text error
DRG-10599 column is not indexed.
From what I gathered you can't create an index on the view, or is that possible afterall (using 10g).
Would it be sufficent to create an index on the column in the table that the view-query is pulling the data from? or can you use the contains funtion on views at all?
Or are there other ways of doing this better?
Thanks,

That particular CONTAINS clause will require a domain index on the column, NAME in your case.
You could also do: select * from view where name in ('Jack', 'Jill')
Depending on your need and number of records and other variables, it may be "fastest" to do the text index on the NAME column. If it is a rather small subset of data and performance is not critical then the IN clause should suffice.

Indexes on a fact table

Hi All,
We are trying to build a data warehouse. The data marts would be accessed by cognos reporting layer. In the data marts we have around 9 dimension tables and 1 fact table. For each month we will have around 21-25 million records in the fact table. Out of 9 dimensions there dim1 and dim2 have 21 million and 10 million records respectively. The rest 7 dimensions are very small like less than 10k records.
In cognos reports they are trying to join the some dimension tables and the fact table to populate some reports. they are taking around 5-6 min.
I have around 8 B-Tree indexes on this fact table with all possible combination of columns. I believe that these many indexes is not improving the performance. So I decided to create a aggregated table with measures. But in cognos there are some reports which give detailed information from the fact table and that are taking around 8 min.
please advice as to what type indexes can be created on fact tables.
I read that we can create bit map indexes based on join conditions but the documentation says that it can include columns only from dimension tables and not fact tables. Should the indexed columns be keys in dimensional tables?
I have observed that the fact table is around 1.5gb. But each index is around 1.9 -2gb. I was kind of surprised when I saw that figure. Does it imply that index scan and table lookup would take more time than the full table scan? And hence it is not using the indexes.
Any help is greatly appreciated.
Thanks
Hari

What sort of queries are you running? Do you have an example (with a query plan)?
Are indexes even useful? Or are you accessing too much data to make indexes worthwhile?
Are you licensed to use partitioning? If so, are your fact tables partitioned? Are the queries doing partition pruning?
Are you using parallelism? If so, is parallel query actually being invoked?
If creating aggregate tables is a potentially useful strategy, you would want to use materialized views with query rewrite.
Justin

How to prevent Oracle from using an index when joining two tables ...

How to prevent Oracle from using an index when joining two tables to get an inline view which is used in an update statement?
O.K. I think I have to explain what I mean:
When joining two tables which have many entries sometimes it es better not to use an index on the column used as join criteria.
I have two tables: table A and table B.
Table A has 4.000.000 entries and table B has 700.000 entries.
I have a join of both tables with a numeric column as join criteria.
There is an index on this column in table A.
So I instead of
where (A.col = B.col)I want to use
where (A.col+0 = B.col)in order to prevent Oracle from using the index.
When I use the join in a select statement it works.
But when I use the join as inline view in an update statement I get the error ORA-01779.
When I remove the "+0" the update statement works. (The column col is unique in table B).
Any ideas why this happens?
Thank you very much in advance for any help.
Regards Hartmut

I think you should post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your query resp. update statement. Please use the \[code\] and \[code\] tags to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Usually if you're using the CBO (cost based optimizer) and have reasonable statistics gathered on the database objects used the optimizer should be able to determine if it is better to use the existing index or not.
Things look different if you don't have statistics, you have outdated/wrong statistics or deliberately still use the RBO (rule based optimizer). In this case you would have to use other means to prevent the index usage, the most obvious would be the already mentioned NO_INDEX or FULL hint.
But I strongly recommend to check in first place why the optimizer apparently seems to choose an inappropriate index access path.
Regards,
Randolf
Oracle related stuff:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Using a Value index on XMLIndex path table.

I am trying to understand how to capitalize on the VALUE index created on a XMLIndex path table. So far, I have not been able to successfully use it. I am not sure whether I am misunderstanding the way it is intended to be used? Or am making a mistake somewhere else along the way. Here is a use-case where I think that it should be getting picked up by the optimizer:
CREATE TABLE TEST_TABLE
    (ID VARCHAR2(128) NOT NULL,
    XML_DATA XMLTYPE NOT NULL,
    CONSTRAINT TEST_PK PRIMARY KEY (ID))
XMLTYPE COLUMN XML_DATA STORE AS BINARY XML;
-- Populate the table with some random data. Here, our single attribute should be
-- unique for each row.
INSERT INTO TEST_TABLE (
SELECT dbms_random.string('A', 15), XMLElement("Test", XMLAttributes(dbms_random.string('A', 15) as "someAttr"))
FROM DUAL
CONNECT BY LEVEL <= 20000 );
CREATE INDEX test_xmlindex_ix ON TEST_TABLE(XML_DATA) INDEXTYPE IS XDB.XMLIndex
PARAMETERS('
    PATHS (Include (/Test/@someAttr))
    PATH TABLE      test_path_table
    PATH ID INDEX   test_path_id_ix
    ORDER KEY INDEX test_key_ix
    VALUE INDEX     test_value_ix ');
-- Not sure if I need these or not?
CALL DBMS_STATS.GATHER_TABLE_STATS ('MYSCHEMA', 'TEST_TABLE');
CALL DBMS_STATS.GATHER_TABLE_STATS ('MYSCHEMA, 'TEST_PATH_TABLE');
-- Now, I would expect this query to use the Value index that was created.
-- Instead, the Explain plan indicates that TEST_PATH_ID_IX was used..
SELECT xml_data
FROM   test_table v
WHERE extractValue(v.xml_data, '/Test/@someAttr') = ?
Here are the operations listed in the explain plan for the query:
SELECT STATEMENT
FILTER
TABLE ACCESS(FULL) MYSCHEMA.TEST_TABLE
TABLE ACCESS(BY INDEX ROWID) MYSCHEMA.TEST_PATH_TABLE
INDEX(RANGE SCAN) MYSCHEMA.TEST_PATH_ID_IXIf I understand everything correctly, here, there is no reason why the PATH ID index should have been used. Isn't this index strictly for the XML tags themselves? Why wouldn't it use the Value index?
Thanks,
Jon

PATH_TABLE
+=======================================================+
| PathID | RID | Order_Key | Locator |     Value      |
|-------------------------------------------------------|
| RAW   | rowid |    RAW    |   RAW   | varchar2(4000) |
|-------------------------------------------------------|
|        |       |           |         |                |
|        |       |           |         |                |
|        |       |           |         |                |
|        |       |           |         |                |
|        |       |           |         |                |
|        |       |           |         |                |
|        |       |           |         |                |
+=======================================================+
XMLIndex
1) PATH INDEX: (PathID, RID)              - BTree
2) ORDER INDEX: (RID, ORDER_KEY)           - BTree
3) VALUE INDEX: (substr("VALUE",1,1599))   - Function Based
Locator: Pointer to XML Fragments
XMLIndex - Namespace issue...
I believe that (although I don't know the exact mechanics) that it will use the path index first to find the needed
tree node / path, then will look for a locator that matches the request and if not will do an full table scan
afterwards, if not successful, trying to limit the request with the filter at hand, so see if it can be used, to
minimize the sub-results.
Message was edited by:
Marco Gralike

Table with FK with no Index created will LOCK TABLE during DML ?

Hi all,
Know that always create index for FK on table as FK's value will 99.9% be use in Where query on table.
Had seen info with regards to the above and had not been successfull trying to simulate the above using:
DROP TABLE "TABLE2";
CREATE TABLE "TABLE2"
   (     "A2" VARCHAR2(10 BYTE),
      CONSTRAINT "PK_A2" PRIMARY KEY ("A2") ENABLE
Insert into TABLE2 (A2) values ('AAA');
Insert into TABLE2 (A2) values ('BBB');
Insert into TABLE2 (A2) values ('CCC');
DROP TABLE "TABLE1";
CREATE TABLE "TABLE1"
   (     "A1" VARCHAR2(10 BYTE),
     "A2" VARCHAR2(10 BYTE),
     "A3" VARCHAR2(10 BYTE),
      CONSTRAINT "PK_A1" PRIMARY KEY ("A1"),
      CONSTRAINT "FK_A1_A2" FOREIGN KEY ("A2")
       REFERENCES "LSD"."TABLE2" ("A2") ENABLE
Insert into TABLE1 (A1,A2,A3) values ('111','AAA','yyy');
Insert into TABLE1 (A1,A2,A3) values ('222','BBB','ZZZ');
When i UPDATE A3 in TABLE1 using '111' record in SQLPlus without COMMIT,
I was able to UPDATE A3 using '222' in another SQLPlus session, so it does not seems like table is LOCK.
Questions.
1. Am using 10GR2, is the above not applicable to 10G ?
2. Or had understand the above concept wrongly ?
Thanks In Advance
Zack

Hi Legatti,
I was able to UPDATE A3 using '222' in another SQLPlus session, so it does not seems like table is LOCK.   Thought that when updating more than 1 record in TABLE1 will caused TABLE1 to be LOCK.
Now, try to perform an update on the TABLE1 like below:    SQL>update table1 set A3='aaa' where A1=111;
And open an another session and perform this SQL below    SQL>delete from table2 where A2='BBB'; -- now it's hangs
Yes !!! Very interesting, it hangs until i do a COMMIT on the UPDATE
and DELETE session shows ORA-02292 Integrity Constraint violated as child record found.
Now, when i create a index for A2 on TABLE1, it DOES NOT HANG and shows ORA-2292 immediately.
So, is this the result of having no index for FK column (A2) on TABLE1 and when doing DML ,
before COMMIT, will result in TABLE2 to be hang upon doing DML on TABLE2 ?
Thanks for the valuable lesson learned.
Zack

Column Order of index on 12M record table

Similar Messages

Maybe you are looking for