"Virtual Index" in a statement.

I thought I read some information about this but cannot locate that info now. Is there such a thing as, for lack of a better phrase, a "virtual index" that can be used in an Oracle SQL select statement?
It would be a hint that defines the column(s) to be used as the index for that specific statement only. The index does not actually exist but Oracle optimizes the query as if it does.
If this exists, could you supply a simple example of the hint-syntax?
Thanks

Re: virtual index
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:21934291902040#21939286863826

Similar Messages

What is the difference between "Invisible" (11g) and "virtual" index?

Hi
What is the difference between the "Invisible" index and "virtual" index?
Thanks
Balaji

Indexes can be visible or invisible. An invisible index is maintained by DML operations and cannot be used by the optimizer. Actually takes space, but is not to be used as part of a potential access path.
AFAIK, a virtual index is created by the tools used in SQL statement access path tuning to provide an alternative for the optimizer to test. It does not take any real space as it is a pure in memory definition.

How to utilize index in selection statement

hi
how to utilize index in selection statement and how is it reduces performance whether another alternative is there to reduce performance .
thanks

Hi Suresh,
For each SQL statement, the database optimizer determines the strategy for accessing data records. Access can be with database indexes (index access), or without database indexes (full table scan).The cost-based database optimizer determines the access strategy on the basis of:
*Conditions in the WHERE clause of the SQL statement
*Database indexes of the table(s) affected
*Selectivity of the table fields contained in the database indexes
*Size of the table(s) affected
*The table and index statistics supply information about the selectivity of table fields, the selectivity of combinations of table fields, and table size. Before a database access is performed, the database optimizer cannot calculate the exact cost of a database access. It uses the information described above to estimate the cost of the database access.The optimization calculation is the amount by which the data blocks to be read (logical read accesses) can be reduced. Data blocks show the level of detail in which data is written to the hard disk or read from the hard disk.
Inroduction to Database Indexes
When you create a database table in the ABAP Dictionary, you must specify the combination of fields that enable an entry within the table to be clearly identified. Position these fields at the top of the table field list, and define them as key fields.
After activating the table, an index is created (for Oracle, Informix, DB2) that consists of all key fields. This index is called a primary index. The primary index is unique by definition. As well as the primary index, you can define one or more secondary indexes for a table in the ABAP Dictionary, and create them on the database. Secondary indexes can be unique or non-unique. Index records and table records are organized in data blocks.
If you dispatch an SQL statement from an ABAP program to the database, the program searches for the data records requested either in the database table itself (full table scan) or by using an index (index unique scan or index range scan). If all fields requested are found in the index using an index scan, the table records do not need to be accessed.
A data block shows the level of detail in which data is written to the hard disk or read from the hard disk. Data blocks may contain multiple data records, but a single data record may be spread across several data blocks.
Data blocks can be index blocks or table blocks. The database organizes the index blocks in the form of a multi-level B* tree. There is a single index block at root level, which contains pointers to the index blocks at branch level. The branch blocks contain either some of the index fields and pointers to index blocks at leaf level, or all index fields and a pointer to the table records organized in table blocks. The index blocks at leaf level contain all index fields and pointers to the table records from the table blocks.
The pointer that identifies one or more table records has a specific name. It is called, for example, ROWID for Oracle databases. The ROWID consists of the number of the database file, the number of the table block, and the row number within the table block.
The index records are stored in the index tree and sorted according to index field. This enables accelerated access using the index. The table records in the table blocks are not sorted.
An index should not consist of too many fields. Having a few very selective fields increases the chance of reusability, and reduces the chance of the database optimizer selecting an unsuitable access path.
Index Unique Scan
If, for all fields in a unique index (primary index or unique secondary index), WHERE conditions are specified with '=' in the WHERE clause, the database optimizer selects the access strategy index unique scan.
For the index unique scan access strategy, the database usually needs to read a maximum of four data blocks (three index blocks and one table block) to access the table record.
select * from VVBAK here vbeln = '00123' ......end select.
In the SELECT statement shown above, the table VVBAK is accessed. The fields MANDT and VBELN form the primary key, and are specified with '=' in the WHERE clause. The database optimizer therefore selects the index unique scan access strategy, and only needs to read four data blocks to find the table record requested.
Index Range Scan
select * from VVBAP here vbeln = '00123' ......end select.
In the example above, not all fields in the primary index of the table VVBAP (key fields MANDT, VBELN, POSNR) are specified with '=' in the WHERE clause. The database optimizer checks a range of index records and deduces the table records from these index records. This access strategy is called an index range scan.
To execute the SQL statement, the DBMS first reads a root block (1) and a branch block (2). The branch block contains pointers to two leaf blocks (3 and 4). In order to find the index records that fulfill the criteria in the WHERE clause of the SQL statement, the DBMS searches through these leaf blocks sequentially. The index records found point to the table records within the table blocks (5 and 6).
If index records from different index blocks point to the same table block, this table block must be read more than once. In the example above, an index record from index block 3 and an index record from index block 4 point to table records in table block 5. This table block must therefore be read twice. In total, seven data blocks (four index blocks and three table blocks) are read.
The index search string is determined by the concatenation of the WHERE conditions for the fields contained in the index. To ensure that as few index blocks as possible are checked, the index search string should be specified starting from the left, without placeholders ('_' or %). Because the index is stored and sorted according to the index fields, a connected range of index records can be checked, and fewer index blocks need to be read.
All index blocks and table blocks read during an index range scan are stored in the data buffer at the top of a LRU (least recently used) list. This can lead to many other data blocks being forced out of the data buffer. Consequently, more physical read accesses become necessary when other SQL statements are executed
DB Indexex :Concatenation
In the concatenation access strategy, one index is reused. Therefore, various index search strings also exist. An index unique scan or an index range scan can be performed for the various index search strings. Duplicate entries in the results set are filtered out when the search results are concatenated.
Select * from vvbap where vbeln in ('00123', '00133', '00134').
endselect.
In the SQL statement above, a WHERE condition with an IN operation is specified over field VBELN. The fields MANDT and VBELN are shown on the left of the primary index. Various index search strings are created, and an index range scan is performed over the primary index for each index search string. Finally, the result is concatenated.
Full Table Scan
select * from vvbap where matnr = '00015'.
endselect
If the database optimizer selects the full table scan access strategy, the table is read sequentially. Index blocks do not need to be read.
For a full table scan, the read table blocks are added to the end of an LRU list. Therefore, no data blocks are forced out of the data buffer. As a result, in order to process a full table scan, comparatively little memory space is required within the data buffer.
The full table scan access strategy is very effective if a large part of a table (for example, 5% of all table records) needs to be read. In the example above, a full table scan is more efficient than access using the primary index.
In Brief
Index unique scan: The index selected is unique (primary index or unique secondary index) and fully specified. One or no table record is returned. This type of access is very effective, because a maximum of four data blocks needs to be read.
Index range scan: The index selected is unique or non-unique. For a non-unique index, this means that not all index fields are specified in the WHERE clause. A range of the index is read and checked. An index range scan may not be as effective as a full table scan. The table records returned can range from none to all.
Full table scan: The whole table is read sequentially. Each table block is read once. Since no index is used, no index blocks are read. The table records returned can range from none to all.
Concatenation: An index is used more than once. Various areas of the index are read and checked. To ensure that the application receives each table record only once, the search results are concatenated to eliminate duplicate entries. The table records returned can range from none to all.
Regards,
Balaji Reddy G
***Rewards if answers are helpful

Virtual Index

Hi,
Can someone give me an explanation for Virtual Indexes? Can I find the info in Oracle documentation? It'll be really grateful if i can get the path/link refers this information. Also what's the difference between Virutal index and invisible indexes?
Thanks in Advance,
Titus Thomas

A virtual index is an index that doesn't really exist (i.e. it occupies 0 space) that can be used to determine whether actually creating an index would cause the optimizer to change a query plan. Tim Hall has an article on [virtual indexes|http://www.oracle-base.com/articles/misc/VirtualIndexes.php] that provides a quick introduction.
Justin

Want to use Index in Select statement

Hi,
I want to use the index tha is created for LIPS table for creation date. I want to use that INdex in the select statement to get the data from that table. Any one can tell me how can I right the select statement in report?
thanks.

Like I mentioned earlier, the optimizer is smart enough to choose the correct index based on the WHERE clause. So if you created an index on field ERDAT for LIPS and your SELECT statement is like so.....
Select ERDAT WERKS MATNR
 from LIPS
 into table Itab
 Where erdat in s_erdat "< - ERDAT First in WHERE Clause
 and werks in s_werks
 and Matnr in s_matnr.
Then the optimizer will choose your index to use to access the data. You can see these if you would do an SQL trace over your program and use the "Explain" button on ST05. It will tell you which index it used and why.
There is no need to use HINTs to force the use of the index.
Regards,
Rich Heilman

Content Index in Unknown state

We are running exchange 2013 with 2 servers in a DAG. On one of the servers we are getting error messages in the event log to do with the search function.
Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The
component operation has failed. --->
Microsoft.Exchange.Search.Engine.FeedingSkippedException: "Feeding was skipped
for 'b0d55635-e3d9-4d83-9661-d7379e1cf0b0 (MDB01)' due to the state 'Unknown',
error code: 'Unknown'." at
Microsoft.Exchange.Search.Engine.SearchFeedingController.InternalExecutionStart()
at
Microsoft.Exchange.Search.Core.Common.Executable.InternalExecutionStart(Object
state) --- End of inner exception stack trace --- at
Microsoft.Exchange.Search.Core.Common.Executable.EndExecute(IAsyncResult
asyncResult) at
Microsoft.Exchange.Search.Engine.SearchRootController.ExecuteComplete(IAsyncResult
asyncResult)
When someone attempts a search which uses the server we get the following message.
Exchange Server Information Store has encountered an error while executing a full-text index query ("string("mark*", mode="and")"). Error information: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]:
Internal error while processing request (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
I have looked on the internet for a solution and so far nothing has helped the issue. I've looked at the content submitters group but I would have thought it would have effected both servers and not just 1.
I've run the script to install the search foundation service but this has not resolved the issue.
Has anyone come across the errors both and resolved the issue?
Thanks
Chris

Hi,
Please check the content index status of databases in DAG. If it's unhealthy, please rebuild content index to check result.
Best regards,
Belinda Ma
TechNet Community Support

ACE 4710 Operations Virtual Servers showing Oper State as N/A

Hi All,
Just wondering if anyone has come across the following issue before:
We currently have a pair of ACE4710 in HA running A3(2.7) and when we have added new virtual servers any new ones show up under the Operations - Virtual Servers window as showing their Oper State as N/A. as follows:
However, clicking on the N/A brings up a window showing that the virtual server is Active and inservice and handling traffic. This doesn't appear to be affect the services using the VIPs that have N/A against them as all appears to be fine.
Just wonder if anyone had seen this before and if there is a reason for it.
Thanks for you help in advance.
Ryan

Thanks for you reply bhartsfield. I mostly work from the CLI as the network engineer but we have server engineers who use the GUI to take things in and out of service if they are conductinh maintenence on the servers. So along with the N/A status it also is missing the current connection count which is also used by the server guys.
The last time I created a VIP I did it via the GUI to see if it was a GUI issue not syncing with the CLI. I have also forced the DM to sync with CLI, but it still has the same results.
Thanks again for your reply, at least I know I am not alone in seeing this behaviour
Regards
Ryan

Proper using of index for parallel statement execution

Hi all,
I've created index for my table
CREATE INDEX ZOO.rep184_med_arcdate ON ZOO.rep184_mediate(arcdate);It was before I started to think about parallel statement execution. As far as I've heard I should alter my index for proper using with parallel hint. Could you please suggest the way to go?

marco wrote:
Hi all,
I've created index for my table
CREATE INDEX ZOO.rep184_med_arcdate ON ZOO.rep184_mediate(arcdate);It was before I started to think about parallel statement execution. As far as I've heard I should alter my index for proper using with parallel hint. Could you please suggest the way to go?when all else fails Read The Fine Manual
http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/sql_elements006.htm#autoId63

New index

Does anyone know of a good tool which can scan a repository of sql statements and determine if a newly proposed index would be used (particularly using RULE based optimization)? I know that Oracle tuning pack does this with Virtual Index Wizard (in cost based mode only), but it only does it on one statement at a time.
Thank you

Randi:
Just add a new blank page to your existing iWeb site, put it at the top in iWeb and add the photo and text you want to it along with a text based hyperlink to the new WP site.
If you have other pages in the existing site you want to have available you could embed the new WP site in an iWeb page like this demo page: Embed One Site Within an iWeb Page. That way you can keep the non blog pages of your existing site (if there are any) and have the new blog included.
If there is nothing in the old site that you want visitor to have access to just put the following code in an HTML snippet on the first page of your current site:
<script type="text/javascript">
parent.window.location = "URL TO NEW WP SITE"; </script>
Thanks to Cyclosaurus for this code
This will immediately redirect visitors to your old site directly to your new one.
OT
Message was edited by: Old Toad

How to populate values in to drop down by index

Hi in my application i have dropdownby index with label State.In that dropdown i need to populate all the states of our country like..Tamilnadu,andhraprdesh,Gujrath,Maharastra,Delhi....,and by default it should be populated with Select State ,can u please tell me the code..
Thanks
Kishore

hi,
1.in ur context create a context value node----eg: MyStates
2.under that value node create a value attribute--eg: values.
3.set the cardinality of "MyStates" value node to 0:n
4.texts property of ur dropdown by index ui element shld be bound to the value attr (values).
5.in the wdDoInit() method of ur view that has this dropdownbyindex ui element use the follwoing code,
String [ ] states_array = new String [ ] {"tn", "mp", "ap", "karnataka"};
List list_for_node_elem = new ArrayList();
 for (int i = 0; i <states_array.length; ++i)
 IPrivateMyView.IMyStatesElement elem = wdContext.createMyStatesElement();
 MyStatesElement.setValues(states_array [i ] );
 list_for_node_elem.add(MyStatesElement);
 wdContext.nodeMyStates().bind(list_fornode_elem);
 wdContext.nodeMyStates().setLeadSelection(1);
Regards
Jayapriya

How to Properly Protect a Virtualized Exchange Server - Log File Discontinuity When Performing Child Partition Snapshot

I'm having problems backing up a Hyper-V virtualized Exchange 2007 server with DPM 2012. The guest has one VHD for the OS, and two pass-through volumes, one for logs and one for the databases. I have three protection groups:
System State - protects only the system state of the mail server, runs at 4AM every morning
Exchange Databases - protects the Exchange stores, 15 minute syncs with an express full at 6:30PM every day
VM - Protecting the server hosting the Exchange VM. Does an child partition snapshot backup of the Exchange server guest with an express full at 9:30PM every day
The problem I'm experiencing is that every time the VM express full completes I start receiving errors on the Exchange Database synchronizations stating that a log file discontinuity was detected. I did some poking around in the logs on the Exchange server
and sure enough, it looks like the child partition snapshot backup is causing Exchange to truncate the log files even though the logs and databases are on pass-through disks and aren't covered by the child partition snapshot.
What is the correct way to back up an entire virtualized Exchange server, system state, databases, OS drive and all?

I just created a new protection group. I added "Backup Using Child Partition Snapshot\MailServer", short-term protection using disk, and automatically create the replica over the network immediately. This new protection group contains only the child partition
snapshot backup. No Exchange backups of any kind.
The replica creation begins. Soon after, the following events show up in the Application log:
=================================
Log Name:      Application
Source:        MSExchangeIS
Date:          10/23/2012 10:41:53 AM
Event ID:      9818
Task Category: Exchange VSS Writer
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      PLYMAIL.mcquay.com
Description:
Exchange VSS Writer (instance 7d26282d-5dec-4a73-bf1c-f55d5c1d1ac7) has been called for "CVssIExchWriter::OnPrepareSnapshot".
=================================
Log Name:      Application
Source:        ESE
Date:          10/23/2012 10:41:53 AM
Event ID:      2005
Task Category: ShadowCopy
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      PLYMAIL.mcquay.com
Description:
Information Store (3572) Shadow copy instance 2051 starting. This will be a Full shadow copy.
=================================
The events continue on, basically snapshotting all of Exchange. From the DPM side, the total amount of data transferred tells me that even though Exhange is trunctating its logs, nothing is actually being sent to the DPM server. So this snapshot operation
seems to be superfluous. ~30 minutes later, when my regularly scheduled Exchange job runs, it fails because of a log file discontinuity.
So, in this case at least, a Hyper-V snapshot backup is definitely causing Exchange to truncate the log files. What can I look at to figure out why this is happening?

Regarding deleting index

Hi Friends,
If I delete the whole content of an Infocube and then do the reload,is it require to delete the index seperately.
If I don't delete the index how is it going to impact the load?
Regards,
Debjani...

It doesn't mean that Indexes will delete permanently .. Structure will remain same!
When you delete data from cube it also deletes the generated indexes which are existed .. there is no point of having indexes on deleted records .. it's logical
even it doesn't hold any data it allows you to create index and generate stats(ex. create a dummy cube and try to generate)
For the moment I don't have any document for it.. I will let know
For your 2nd ques.
Only for huge loads droping index will be usefull which will improve the loading performance!
For daily delta load with less volume of data you need not to drop Indexes .. if you do so it will take lot of time to rebuild the indexes(on whole data)

Why does not my query use an index?

I have a table with some processed rows (state: 9) and some unprocessed rows (states: 0,1,2,3,4).
This table has over 120000 rows, but this number will grow.
Most of the rows are processed and most of them also contain a group id. Number of groups is relatively small (let's assume 20).
I would like to obtain the oldest some_date for every group. This values has to be outer joined to a on-line report (contains one row for each group).
Here is my set-up:
Tested on: 10.2.0.4 (Solaris), 10.2.0.1 (WinXp)
drop table t purge;
create table t(
id number not null primary key,
grp_id number,
state number,
some_date date,
pad char(200)
insert into t(id, grp_id, state, some_date, pad)
select level,
 trunc(dbms_random.value(0,20)),
 9,
 sysdate+dbms_random.value(1,100),
 'x'
from dual
connect by level <= 120000;
insert into t(id, grp_id, state, some_date, pad)
select level + 120000,
 trunc(dbms_random.value(0,20)),
 trunc(dbms_random.value(0,5)),
 sysdate+dbms_random.value(1,100),
 'x'
from dual
connect by level <= 2000;
commit;
exec dbms_stats.gather_table_stats(user, 'T', estimate_percent=>100, method_opt=>'FOR ALL COLUMNS SIZE 1');
Tom Kyte's printtab
==============================
TABLE_NAME : T
NUM_ROWS : 122000
BLOCKS : 3834I know, this could be easily solved by fast refresh on commit materialized view like this:
select
grp_id,
min(some_date),
from
t
where
state in (0,1,2,3,4)
grpup by
grp_id;+ I have to create log on (grp_id, some_date, state)
Number of rows with active state will be always relatively small. Let's assume 1000-2000.
So my another idea was to create a selective index. An index which would contain only data for rows with an active state.
Something like this:
create index fidx_active on t (
case state
 when 0 then grp_id
 when 1 then grp_id
 when 2 then grp_id
 when 3 then grp_id
 when 4 then grp_id
end,
case state
 when 0 then some_date
 when 1 then some_date
 when 2 then some_date
 when 3 then some_date
 when 4 then some_date
end) compress 1; so a tuple (group_id, some_date) is projected to tuple (null, null) when the state is not an active state and therefore it is not indexed.
We can save even more space by compressing 1st expression.
analyze index idx_grp_state_date validate structure;
select * from index_stats
@pr
Tom Kyte's printtab
==============================
HEIGHT : 2
BLOCKS : 16
NAME : FIDX_ACTIV
LF_ROWS : 2000 <-- we're indexing only active rows
LF_BLKS : 6 <-- small index: 1 root block with 6 leaf blocks
BR_ROWS : 5
BR_BLKS : 1
DISTINCT_KEYS : 2000
PCT_USED : 69
PRE_ROWS : 25
PRE_ROWS_LEN : 224
OPT_CMPR_COUNT : 1
OPT_CMPR_PCTSAVE : 0Note: @pr is a Tom Kyte's print table script adopted by Tanel Poder (I'm using Tanel's library) .
Then I created a query to be outer joined to the report (report contains a row for every group).
I want to achieve a full scan of the index.
select
case state -- 1st expression
 when 0 then grp_id
 when 1 then grp_id
 when 2 then grp_id
 when 3 then grp_id
 when 4 then grp_id
end grp_id,
min(case state --second expression
 when 0 then some_date
 when 1 then some_date
 when 2 then some_date
 when 3 then some_date
 when 4 then some_date
 end) as mintime
from t
where
case state --1st expression: at least one index column has to be not null
 when 0 then grp_id
 when 1 then grp_id
 when 2 then grp_id
 when 3 then grp_id
 when 4 then grp_id
end is not null
group by
case state --1st expression
 when 0 then grp_id
 when 1 then grp_id
 when 2 then grp_id
 when 3 then grp_id
 when 4 then grp_id
end;-------------
Doc's snippet:
13.5.3.6 Full Scans
A full scan is available if a predicate references one of the columns in the index. The predicate does not need to be an index driver. A full scan is also available when there is no predicate, if both the following conditions are met:
All of the columns in the table referenced in the query are included in the index.
At least one of the index columns is not null.
A full scan can be used to eliminate a sort operation, because the data is ordered by the index key. It reads the blocks singly.
13.5.3.7 Fast Full Index Scans
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 NOT NULL constraint. A 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.
You can specify fast full index scans with the initialization parameter OPTIMIZER_FEATURES_ENABLE or the INDEX_FFS hint. 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.
So the question is: Why does oracle do a full table scan?
Everything needed is in the index and one expression is not null, but index (fast) full scan is not even considered by CBO (I did a 10053 trace)
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 1 | 85 | 20 |00:00:00.11 | 3841 |
|* 2 | TABLE ACCESS FULL| T | 1 | 6100 | 2000 |00:00:00.10 | 3841 |
Predicate Information (identified by operation id):
 2 - filter(CASE "STATE" WHEN 0 THEN "GRP_ID" WHEN 1 THEN "GRP_ID" WHEN 2
 THEN "GRP_ID" WHEN 3 THEN "GRP_ID" WHEN 4 THEN "GRP_ID" END IS NOT NULL)Let's try some minimalistic examples. Firstly with no FBI.
create index idx_grp_id on t(grp_id);
select grp_id,
 min(grp_id) min
from t
where grp_id is not null
group by grp_id;
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 1 | HASH GROUP BY | | 1 | 20 | 20 |00:00:01.00 | 244 | 237 |
|* 2 | INDEX FAST FULL SCAN| IDX_GRP_ID | 1 | 122K| 122K|00:00:00.54 | 244 | 237 |
Predicate Information (identified by operation id):
 2 - filter("GRP_ID" IS NOT NULL)This kind of output I was expected to see with FBI. Index FFS was used although grp_id has no NOT NULL constraint.
Let's try a simple FBI.
create index fidx_grp_id on t(trunc(grp_id));
select trunc(grp_id),
 min(trunc(grp_id)) min
from t
where trunc(grp_id) is not null
group by trunc(grp_id);
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 1 | 20 | 20 |00:00:00.94 | 3841 |
|* 2 | TABLE ACCESS FULL| T | 1 | 6100 | 122K|00:00:00.49 | 3841 |
Predicate Information (identified by operation id):
 2 - filter(TRUNC("GRP_ID") IS NOT NULL)Again, index (fast) full scan not even considered by CBO.
I tried:
alter table t modify grp_id not null;
alter table t add constraint trunc_not_null check (trunc(grp_id) is not null);I even tried to set table hidden column (SYS_NC00008$) to NOT NULL
It has no effect, FTS is still used..
Let's try another query:
select distinct trunc(grp_id)
from t
where trunc(grp_id) is not null
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH UNIQUE | | 1 | 20 | 20 |00:00:00.85 | 244 |
|* 2 | INDEX FAST FULL SCAN| FIDX_GRP_ID | 1 | 122K| 122K|00:00:00.49 | 244 |
Predicate Information (identified by operation id):
 2 - filter("T"."SYS_NC00008$" IS NOT NULL)Here the index FFS is used..
Let's try one more query, very similar to the above query:
select trunc(grp_id)
from t
where trunc(grp_id) is not null
group by trunc(grp_id)
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 1 | 20 | 20 |00:00:00.86 | 3841 |
|* 2 | TABLE ACCESS FULL| T | 1 | 122K| 122K|00:00:00.49 | 3841 |
Predicate Information (identified by operation id):
 2 - filter(TRUNC("GRP_ID") IS NOT NULL)And again no index full scan..
So my next question is:
What are the restrictions which prevent index (fast) fullscan to be used in these scenarios?
Thank you very much for your answers.
Edited by: user1175494 on 16.11.2010 15:23
Edited by: user1175494 on 16.11.2010 15:25

I'll start off with the caveat that i'm no Johnathan Lewis so hopefully someone will be able to come along and give you a more coherent explanation than i'm going to attempt here.
It looks like the application of the MIN function against the case statement is confusing the optimizer and disallowing the usage of your FBI. I tested this against my 11.2.0.1 instance and your query chooses the fast full scan without being nudged in the right direction.
That being said, i was able to get this to use a fast full scan on my 10 instance, but i had to jiggle the wires a bit. I modified your original query slightly, just to make it easier to do my fiddling.
original (in the sense that it still takes the full table scan) query
with data as
select
 case state -- 1st expression
 when 0 then grp_id
 when 1 then grp_id
 when 2 then grp_id
 when 3 then grp_id
 when 4 then grp_id
 end as grp_id,
 case state --second expression
 when 0 then some_date
 when 1 then some_date
 when 2 then some_date
 when 3 then some_date
 when 4 then some_date
 end as mintime
from t
where
 case state --1st expression: at least one index column has to be not null
 when 0 then grp_id
 when 1 then grp_id
 when 2 then grp_id
 when 3 then grp_id
 when 4 then grp_id
 end is not null
and
 case state --second expression
 when 0 then some_date
 when 1 then some_date
 when 2 then some_date
 when 3 then some_date
 when 4 then some_date
 end is not null
select--+ GATHER_PLAN_STATISTICS
grp_id,
min(mintime)
from data
group by grp_id;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'allstats +peeked_binds'));
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 2 | 33 | 40 |00:00:00.07 | 7646 |
|* 2 | TABLE ACCESS FULL| T | 2 | 33 | 4000 |00:00:00.08 | 7646 |
Predicate Information (identified by operation id):
 2 - filter((CASE "STATE" WHEN 0 THEN "GRP_ID" WHEN 1 THEN "GRP_ID" WHEN 2
 THEN "GRP_ID" WHEN 3 THEN "GRP_ID" WHEN 4 THEN "GRP_ID" END IS NOT NULL AND
 CASE "STATE" WHEN 0 THEN "SOME_DATE" WHEN 1 THEN "SOME_DATE" WHEN 2 THEN
 "SOME_DATE" WHEN 3 THEN "SOME_DATE" WHEN 4 THEN "SOME_DATE" END IS NOT
 NULL))
modified version where we prevent the MIN function from being applied too early, by using ROWNUM
with data as
select
 case state -- 1st expression
 when 0 then grp_id
 when 1 then grp_id
 when 2 then grp_id
 when 3 then grp_id
 when 4 then grp_id
 end as grp_id,
 case state --second expression
 when 0 then some_date
 when 1 then some_date
 when 2 then some_date
 when 3 then some_date
 when 4 then some_date
 end as mintime
from t
where
 case state --1st expression: at least one index column has to be not null
 when 0 then grp_id
 when 1 then grp_id
 when 2 then grp_id
 when 3 then grp_id
 when 4 then grp_id
 end is not null
and
 case state --second expression
 when 0 then some_date
 when 1 then some_date
 when 2 then some_date
 when 3 then some_date
 when 4 then some_date
 end is not null
and rownum > 0
select--+ GATHER_PLAN_STATISTICS
grp_id,
min(mintime)
from data
group by grp_id;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'allstats +peeked_binds'));
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
| 1 | HASH GROUP BY | | 2 | 20 | 40 |00:00:00.01 | 18 |
| 2 | VIEW | | 2 | 33 | 4000 |00:00:00.07 | 18 |
| 3 | COUNT | | 2 | | 4000 |00:00:00.05 | 18 |
|* 4 | FILTER | | 2 | | 4000 |00:00:00.03 | 18 |
|* 5 | INDEX FAST FULL SCAN| FIDX_ACTIVE | 2 | 33 | 4000 |00:00:00.01 | 18 |
Predicate Information (identified by operation id):
 4 - filter(ROWNUM>0)
 5 - filter(("T"."SYS_NC00006$" IS NOT NULL AND "T"."SYS_NC00007$" IS NOT NULL))

How can I create index(uniqie index) for a existed table?

Hi guys,
I want to create a index for a existed table, it should be unique index. I did it using se11, "indexes," and select the radio button "unqiue index", of course the fields as well. But when I activate it, I get a waring and therefore can not create this index. But if I select radio button "non-uniqe index", it works.
However I have to reate a unqiue index.
How can I do it?
Thanks in advance
Regards,
Liying

HI Wang
You can create your index via SE11, enter the table name, click change, choose Go To, Indexes. Here create your index with the key fields that you want. To use the index, your select statement WHERE clause, you must have the key fields of the index in the order that they appear in the index. The "optimizer" will choose the index depending on your fields of the WHERE clause.
One thing to remember is that when you create indexes for tables, the update or insert of these tables may have a slower response then before, I for one have never seen a big problem as of yet.
this Document may help u on primary and secondary indexes :
http://jdc.joy.com/helpdata/EN/cf/21eb20446011d189700000e8322d00/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb47446011d189700000e8322d00/content.htm
If it helps Reward the points
Regards,
Rk
Message was edited by:
Rk Pasupuleti

How to maintain bitmap index on a large table in DW?

Hi all,
We have many tables which are constantly doing either FULL or INCREMENTAL loading.
And we have created many BITMAP indexes and several B*Tree index (caused by PRIMARY KEY or UNIQUE key constraints) on those tables.
So, what I want to know is, how to maintain those BITMAP (and B*Tree) indexes for different loading mode?
like, should I drop the index before the full load and re-create it after that?
and do nothing in INCREMENTAL loading? I am aware that it will take more time to load with indexes.
any links, books, articles or opinions would be highly appreciated.
Thanks

Just to reiterate, add to what Adam said. From Oracle Doc
http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/indexes002.htm#CIHJIDJG
Unusable indexes
An unusable index is ignored by the optimizer and is not maintained by DML. One reason to make an index unusable is to improve bulk load performance. (Bulk loads go more quickly if the database does not need to maintain indexes when inserting rows.) Instead of dropping the index and later re-creating it, which requires you to recall the exact parameters of the CREATE INDEX statement, you can make the index unusable, and then rebuild it.
You can create an index in the unusable state, or you can mark an existing index or index partition unusable. In some cases the database may mark an index unusable, such as when a failure occurs while building the index. When one partition of a partitioned index is marked unusable, the other partitions of the index remain valid.
An unusable index or index partition must be rebuilt, or dropped and re-created, before it can be used. Truncating a table makes an unusable index valid.
Beginning with Oracle Database 11g Release 2, when you make an existing index unusable, its index segment is dropped.
The functionality of unusable indexes depends on the setting of the SKIP_UNUSABLE_INDEXES initialization parameter. When SKIP_UNUSABLE_INDEXES is TRUE (the default), then:
•DML statements against the table proceed, but unusable indexes are not maintained.
•DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
•For nonpartitioned indexes, the optimizer does not consider any unusable indexes when creating an access plan for SELECT statements. The only exception is when an index is explicitly specified with the INDEX() hint.
•For a partitioned index where one or more of the partitions are unusable, the optimizer does not consider the index if it cannot determine at query compilation time if any of the index partitions can be pruned. This is true for both partitioned and nonpartitioned tables. The only exception is when an index is explicitly specified with the INDEX() hint.
When SKIP_UNUSABLE_INDEXES is FALSE, then:
•If any unusable indexes or index partitions are present, any DML statements that would cause those indexes or index partitions to be updated are terminated with an error.
•For SELECT statements, if an unusable index or unusable index partition is present but the optimizer does not choose to use it for the access plan, the statement proceeds. However, if the optimizer does choose to use the unusable index or unusable index partition, the statement terminates with an error.
Incremental load really matters the volume and whether for new dats you just add new partitions or subpartitions . If my incremntal go all over place and/or if I am touching few thousand rows. Yes might want to keep the indexes valid and let Oracle maintain it. IF millions added or incremental data just added to new part/subpart . Keeping indexes unsable for those partitions/subpartitions and the rebuilding it later may yield better results.

"Virtual Index" in a statement.

Similar Messages

Maybe you are looking for