Rowid in IOT table

It seems that rowid in IOT is
created by function involving primary key.
is there any built in function or package
that we use to simulate that ?
null

Think about what a ROWID actually is and it will become clear.
"The rowid of a row specifies the datafile and data block containing the row and the location of the row in that block."

Similar Messages

IOT table in highly concurrent env

Hi All,
I have done some bench marking of IOT vs Heap tables and found that updates are lot faster on an IOT table. We will have select, update and inserts on the table we are considering, delete are probably rare - we will drop a partition when we want to delete rows during a maintanence window.
Does anyone see any issues using IOT table in a highly concurrent DML activity (OLTP) env? If so could you please share any experineces?
Thanks a lot,
Vissu

Hi All,
I have done some bench marking of IOT vs Heap tables and found that updates are lot faster on an IOT table. We will have select, update and inserts on the table we are considering, delete are probably rare - we will drop a partition when we want to delete rows during a maintanence window.
Does anyone see any issues using IOT table in a highly concurrent DML activity (OLTP) env? If so could you please share any experineces?
Thanks a lot,
Vissu

Iot table column modify

Oracle Database 10g Release 10.2.0.1.0 - Production
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
we have iot table which has 7.7 million record ,in production environment and i need to modify one column of this table say "T"
i planned to
create new table "copy_T" with create table as select and
truncate "T" and
modify "T"
i inserted again all records from copy_T to T with
insert into T select * from copyT
what is the best approach for this case
Message was edited by:
JAA
Message was edited by:
JAA

Create a temporary table with parallel execution and Truncate the old table ( better rename the table) and
Rename the temporary table to the required table name

ROWID and IOTs

Greetings,
I've got some dynamic SQL that selects based on ROWID. Works OK until the table argument is an IOT.
ORA-01410: invalid ROWIDI have been made aware that IOTs do not carry valid ROWIDs, however, when a ROWID is selected from an IOT, values that can be handled as VARCHAR2 are returned.
SQL> select rowid from my_iot_table;
ROWID
*BAgA7EYCwgsCwQX+
*BAgA7EYCwgsCwQ7+
*BAgA7EYCwgsCwRX+If I handle these ROWIDs as character data, is there any guarantee of uniqueness?
-Kevin

In a single transaction, I've got a bit of (recursive) code that traverses a tree of related rows in various tables. At each node, it caches the current rowid and compares it to those of all visited nodes to determine if any cycles exist in the data.
Rowid seemed to be a convenient test for uniqueness.
-K

TEMP table & IOT table

Hi all,
I have the following observation related to TEMP table. I am wondering if it is always correct.
When you query dba_tables the tablespace_name is empty if it is a temporary table. Also it has 0 records.
Also I just found one index organized table in our db (first time see this creature) based on iot_type = ‘IOT’. It also has tablespace_name column empty and 0 records in table. Based on the knowledge I got from reading the index organized table should just like regular table except that its data is sorted when saved in the database. So if it is being used it should have non zero records in the table, right?
Thanks a lot for your info.
Shirley

Hi..
21:37:05 ravan >conn anand/xxxxxx
Connected.
21:37:46 ravan >21:38:01 ravan >CREATE TABLE t1 (c1 NUMBER PRIMARY KEY, c2 VARCHAR2(30)) ORGANIZATION INDEX tablespace users;
Table created.
Elapsed: 00:00:00.01
21:38:51 ravan >select OWNER,TABLE_NAME,TABLESPACE_NAME,IOT_NAME,IOT_TYPE from dba_tables where table_name='T1';
OWNER                          TABLE_NAME                     TABLESPACE_NAME                IOT_NAME                       IOT_TYPE
ANAND                          T1                                                                                   IOT
21:49:02 ravan >insert into t1 values (1,'a');
1 row created.
Elapsed: 00:00:00.00
21:49:21 ravan >insert into t1 values (2,'b');
1 row created.
Elapsed: 00:00:00.00
21:49:25 ravan >insert into t1 values (3,'c');
1 row created.
Elapsed: 00:00:00.00
21:49:29 ravan >insert into t1 values (4,'d');
1 row created.
Elapsed: 00:00:00.00
21:49:33 ravan >
21:49:34 ravan >commit;
Commit complete.
Elapsed: 00:00:00.00
21:49:36 ravan >
21:49:36 ravan >
21:49:36 ravan >
21:49:37 ravan >select * from t1;
        C1 C2
         1 a
         2 b
         3 c
         4 d
Elapsed: 00:00:00.00
21:50:40 ravan >conn sys/xxxxxx as sysdba
Connected.
21:51:20 ravan >exec dbms_stats.gather_table_stats(ownname =>'ANAND',tabname =>'T1',cascade =>true);
PL/SQL procedure successfully completed.
21:55:34 ravan >select table_name,owner,tablespace_name,num_rows,last_analyzed,avg_row_len,blocks FROM dba_tables WHERE table_name like UPPER('%&table_name%');
Enter value for table_name: t1
TABLE_NAME                     OWNER                          TABLESPACE_NAME        NUM_ROWS LAST_ANAL AVG_ROW_LEN     BLOCKS
T1                             ANAND                                                        4 05-MAR-09           5
21:56:50 ravan >select table_owner,table_name,owner AS index_owner,index_name,tablespace_name,num_rows,status,index_type FROM dba_indexes WHERE table_owner = UPPER('&owner') AND table_name = UPPER('&table_name') ORDER BY table_owner, table_name, index_owner, index_name;
Enter value for owner: anand
Enter value for table_name: t1
TABLE_OWNER          TABLE_NAME                     INDEX_OWNER          INDEX_NAME                  TABLESPACE_NAME        NUM_ROWS STATUS      INDEX_TYPE
ANAND                T1                             ANAND                SYS_IOT_TOP_28811           USERS                            4 VALID    IOT - TOP
Elapsed: 00:00:00.00HTH
Anand

IOT tables ..Analyze

I see that Oracle Index Organized Tables are not getting analyzed by itself. Is this expected? Do i need to analyze this table manually ?
We are using 10.1.0.5
Thanks

Look at the dbms_iot built-in package
http://www.psoug.org/reference/dbms_iot.html

Partitioned tables and IOT

Hi All,
We had a database using IOT but now because of the performance reasons
we want to elimnate IOT table and using the Parititioned Tables.
Have you ever using the partitioned tables for ORACLE with your database?
If you have done that please share your experiences or refer me some
documents related to Partitioned tables for ORACLE to make my job more
easier.
Thanks in advance,
JP

Hi,
You will get good information from this Oracle site,
http://www.oracle.com/technology/documentation/index.html.
Thanks

DataPump imp: Re-organization a Heap table to IOT compressed table

Hello,
I'd like to re-organize a heap table to IOT TABLE the heap table has a size of 25GB.
After do the expdp table I drop the heap table and create the table as IOT using the compress 2 option. Because this table has a 9 PK columns the compress prefix optimal is 2.
After, I run the impdp with the option accesss_method=direct_path (to avoid UNDO generation). The IOT index is not compressed. I doing a alter table TAB_IOT move compress, the compress work becasuse the segment reduction.
The question is exists any way to force the compression at import phase to reduce steps and storage resources.
My env is Oracle 11.1.0.7 on LInux-x64.
Many thanks
Arturo

DBMS_REDEFINITION
http://www.morganslibrary.org/reference/pkgs/dbms_redefinition.html
It is not going to happen in any respect with DataPump.

Cannot select ROWID from a join view without a key-preserved table at OCI c

Hi All,
Can anybody help me..?
When i am creating the request in the presentation services ..
for some of the columns i am getting the following error..by removing those those columns it's working fine..
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 17001] Oracle Error code: 1445, message: ORA-01445: cannot select ROWID from a join view without a key-preserved table at OCI call OCIStmtExecute. [nQSError: 17010] SQL statement preparation failed. (HY000)
Please suggest me a solution..
Thanks in Advance...

Looks like you have a view that contains the ROWID of another table. Does the view work first from sqlplus? See whether it returns any data. Its a ORA- specific error. So, the error is related to your view rather than BI EE. Also, how many columns are you trying to pull in your report?
Thanks,
Venkat
http://oraclebizint.wordpress.com

Index Organized Tables

what is logical rowid in IOT?are they stored somwhere physically just like physical rowId's
what are secondary indexes?
what it means by leaf block splits?when and how it happens?
and the primary key constraint for an index-organized table cannot be dropped, deferred, or disabled,,,,,Is it true,,,,,if Yes Then Y
how does overflow works?how the two clauses are implemented PCTTHRESHOLD and INCLUDING.how they work?
Edited by: Juhi on Oct 22, 2008 1:09 PM

I'm sort-of tempted to just point you in the direction of the official documentation (the concepts guide would be a start. See http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/schema.htm#sthref759)
But I would say one or two other things.
First, physical rowids are not stored physically. I don't know why you'd think they were. The ROWID data type can certainly be used to store a rowid if you choose to do so, but if you do something like 'select rowid from scott.emp', for example, you'll see rowids that are generated on-the-fly. ROWID is a pseudo-column, not physically stored anywhere, but computed whenever needed.
The difference between a physical rowid and a logical one used with IOTs comes down to a bit of relational database theory. It is a cast-iron rule of relational databases that a row, once inserted into a table, must never move. That is, the rowid it is assigned at the moment of its first insertion, must be the rowid it 'holds onto' for ever and ever. If you ever want to change the rowids assigned to rows in an ordinary table, you have to export them, truncate the table and then re-insert them: fresh insert, fresh rowid. (Oracle bends this rule for various maintenance and management purposes, whereby 'enable row movement' permits rows to move within a table, but the general case still applies mostly).
That rule is obviously hopeless for index structures. Were it true, an index entry for 'Bob' who gets updated to 'Robert' would find itself next to entries for 'Adam' and 'Charlie', even though it now has an 'R' value. Effectively, a 'b' "row" in an index must be allowed to "move" to an 'r' sort of block if that's the sort of update that takes place. (In practice, an update to an index entry consists of performing a delete followed by a re-insert, but the physicalities don't change the principle: "rows" in an index must be allowed to move if their value changes; rows in a table don't move, whatever happens to their values)
An IOT is, at the end of the day, simply an index with a lot more columns in it than a "normal" index would have -so it, too, has to allow its entires (its 'rows', if you like) to move. Therefore, an IOT cannot use a standard ROWID, which is assigned once and forever. Instead, it has to use something which takes account of the fact that its rows might wander. That is the logical rowid. It's no more "physical" than a physical rowid -neither are physically stored anywhere. But a 'physical' rowid is invariant; a logical one is not. The logical one is actually constructed in part from the primary key of the IOT -and that's the main reason why you cannot ever get rid of the primary key constraint on the IOT. Being allowed to do so would equate to allowing you to destroy the one organising principle for its contents that an IOT possesses.
(See the section entitled "The ROWID Pseudocolumn" and following on this page: http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT1845
So IOTs have their data stored in them in primary key order. But they don't just contain the primary key, but every other column in the 'table definition' too. Therefore, just like with an ordinary table, you might want sometimes to search for data on columns which are NOT part of the primary key -and in that case, you might well want these non-primary key columns to be indexed. Therefore, you will create ordinary indexes on these columns -at this point, you're creating an index on an index, really, but that's a side issue, too! These extra indexes are called 'secondary indexes', simply because they are 'subsidiary indexes' to the main one, which is the "table" itself arranged in primary key order.
Finally, a leaf block split is simply what happens when you have to make room for new data in an index block which is already packed to the rafters with existing data. Imagine an index block can only contain four entries, for example. You fill it with entries for Adam, Bob, Charlie, David. You now insert a new record for 'Brian'. If this was a table, you could throw Brian into any new block you like: data in a table has no positional significance. But entries in an index MUST have positional significance: you can't just throw Brian in amongst the middle of a lot of Roberts, Susans and Tanyas. Brian HAS to go in between the existing entires for Bob and Charlie. Yet you can't just put him in the middle of those two, because then you'd have five entries in a block, not four, which we imagined for the moment to be the maximum allowed. So what to do? What you do is: obtain a new, empty block. Move Charlie and David's entries into the new block. Now you have two blocks: Adam-Bob and Charlie-David. Each only has two entries, so each has two 'spaces' to accept new entries. Now you have room to add in the entry for Brian... and so you end up with Adam-Bob-Brian and Charlie-David.
The process of moving some index entries out of one block into a new one so that there's room to allow new entries to be inserted in the middle of existing ones is called a block split. They happen for other reasons, too, so this is just a gloss treatment of them, but they give you the basic idea. It's because of block splits that indexes (and hence IOTs) see their "rows" move: Charlie and David started in one block and ended up in a completely different block because of a new (and completely unrelated to them) insert.
Very finally, overflow is simply a way of splitting off data into a separate table segment that wouldn't sensibly be stored in the main IOT segment itself. Suppose you create an IOT containing four columns: one, a numeric sequence number; two, a varchar2(10); three, a varchar2(15); and four, a blob. Column 1 is the primary key.
The first three columns are small and relatively compact. The fourth column is a blob data type -so it could be storing entire DVD movies, multi-gigabyte-sized monsters. Do you really want your index segment (for that is what an IOT really is) to balloon to huge sizes every time you add a new row? Probably not. You probably want columns 1 to 3 stored in the IOT, but column 4 can be bumped off over to some segment on its own (the overflow segment, in fact), and a link (actually, a physical rowid pointer) can link from the one to the other. Left to its own devices, an IOT will chop off every column after the primary key one when a record which threatens to consume more than 50% of a block gets inserted. However, to keep the main IOT small and compact and yet still contain non-primary key data, you can alter these default settings. INCLUDE, for example, allows you to specify which last non-primary key column should be the point at which a record is divided between 'keep in IOT' and 'move out to overflow segment'. You might say 'INCLUDE COL3' in the earlier example, so that COL1, COL2 and COL3 stay in the IOT and only COL4 overflows. And PCTTHRESHOLD can be set to, say, 5 or 10 so that you try to ensure an IOT block always contains 10 to 20 records -instead of the 2 you'd end up with if the default 50% kicked in.

Null values v IOT with primary constraint

Hi gurus.
I've overheard boss' conversation with client, who complaints that one of the columns in a system IOT table with NOT NULL and PRIMARY KEY returns nulls.
Do you have any ideas? I do not have access to this DB, I just wonder, how it could be and what are these points, that we should start with.
Thank you in advance,
Maria.

ou, sorry if I was not so clear, but I'm absolutely calm and even more: it's not my responsibility at all to fix that problem :-))
all that I wanted is just to find some weak places where the reason of the problem could exists and give it my boss while he is busy with his time consuming project (in short, i just wanted to help him to resolve it, not waiting while he will ask me to do that). nobody is in panic, everything is ok in a world.
clear description:
client has a system table (IOT) that sometimes returns null values from column with NOT NULL and PRIMARY KEY constraint. as I remember from school, it's impossible. client wonders if it's an Oracle 9i bug and upgrade to 10g will fix it, or it's a block corruption. I do't know the answer, that's why I'm asking you, Oracle's gurus.
Thank you all,
M.

Does the 'default where clause' query select the ROWID by default ?

Hi ,
The query in default where property of a data block is as follows:
global.prim_lang = :global.user_lang
and upper(group_name) like upper('%' || :B_apply_inclusions.TI_group_desc || '%')
UNION ALL
select g.rowid, g.group_no
from table1 t,
table 2 g
where :global.prim_lang != :global.user_lang
and upper(g.group_name) = t.key(+)
and :global.user_lang = t.lang(+)
and upper(nvl(t.translated_value, g.group_name)) like upper('%' || :B_apply_inclusions.TI_group_desc || '%')
The g.rowid was added in the UNIONALL portion of the query because the first part of the query was bringing rowid as well.
We are in 10.1.2.3.0 forms version.
However for a user in forms verion 10.1.2.0.2, the query is giving an error " Unable to perform query " - due to mismatch in the number of columns selected in the query union.
because for this user, rowid is not selected as part of default where clause query( 1st part of the query before the unionalll).
If g.rowid is removed from the 2nd part of the query , it errors out in 10.1.2.3.0 forms version.
Could you kindly clarify when this rowid will also be selected by the default where clause of a block and why this issue is occuring?Is this issue related to forms version or any other property of the block? Is it is version based, is there a patch available to deal with the same?
Thanks in Advance.

You normally change the default_where block property just when you want to chnage the filter conditions for what is selected from a given block data source.
Querries with union or minus will confuse forms as to the rowid and will no longer be albe to perform the default insert/update/delete, not knowing the rowid and the table to perform the dml on.
A from clause query will be the best way to change dynamically the tables you select from and also the where. But, by using that, if you wish to insert/update/delete, you will have to use on-insert/update/delete triggers where the processing will have to rely on some primary key columns and not on rowid.
Or, instead of a from-clause, you may use a view, but that will definitely be less flexible than a from clause query.

Tables in subquery resulting in full table scans

Hi,
This is related to a p1 bug 13009447. Customer recently upgraded to 10G. Customer reported this type of problem for the second time.
Problem Description:
All the tables in sub-query are resulting in full table scans and hence are executing for hours.
Here is the query
SELECT /*+ PARALLEL*/
act.assignment_action_id
, act.assignment_id
, act.tax_unit_id
, as1.person_id
, as1.effective_start_date
, as1.primary_flag
FROM pay_payroll_actions pa1
, pay_population_ranges pop
, per_periods_of_service pos
, per_all_assignments_f as1
, pay_assignment_actions act
, pay_payroll_actions pa2
, pay_action_classifications pcl
, per_all_assignments_f as2
WHERE pa1.payroll_action_id = :b2
AND pa2.payroll_id = pa1.payroll_id
AND pa2.effective_date
BETWEEN pa1.start_date
AND pa1.effective_date
AND act.payroll_action_id = pa2.payroll_action_id
AND act.action_status IN ('C', 'S')
AND pcl.classification_name = :b3
AND pa2.consolidation_set_id = pa1.consolidation_set_id
AND pa2.action_type = pcl.action_type
AND nvl (pa2.future_process_mode, 'Y') = 'Y'
AND as1.assignment_id = act.assignment_id
AND pa1.effective_date
BETWEEN as1.effective_start_date
AND as1.effective_end_date
AND as2.assignment_id = act.assignment_id
AND pa2.effective_date
BETWEEN as2.effective_start_date
AND as2.effective_end_date
AND as2.payroll_id = as1.payroll_id
AND pos.period_of_service_id = as1.period_of_service_id
AND pop.payroll_action_id = :b2
AND pop.chunk_number = :b1
AND pos.person_id = pop.person_id
AND (
as1.payroll_id = pa1.payroll_id
OR pa1.payroll_id IS NULL
AND NOT EXISTS
SELECT /*+ PARALLEL*/ NULL
FROM pay_assignment_actions ac2
, pay_payroll_actions pa3
, pay_action_interlocks int
WHERE int.locked_action_id = act.assignment_action_id
AND ac2.assignment_action_id = int.locking_action_id
AND pa3.payroll_action_id = ac2.payroll_action_id
AND pa3.action_type IN ('P', 'U')
AND NOT EXISTS
SELECT /*+ PARALLEL*/
NULL
FROM per_all_assignments_f as3
, pay_assignment_actions ac3
WHERE :b4 = 'N'
AND ac3.payroll_action_id = pa2.payroll_action_id
AND ac3.action_status NOT IN ('C', 'S')
AND as3.assignment_id = ac3.assignment_id
AND pa2.effective_date
BETWEEN as3.effective_start_date
AND as3.effective_end_date
AND as3.person_id = as2.person_id
ORDER BY as1.person_id
, as1.primary_flag DESC
, as1.effective_start_date
, act.assignment_id
FOR UPDATE OF as1.assignment_id
, pos.period_of_service_id
Here is the execution plan for this query. We tried adding hints in sub-query to force indexes to pick-up but it is still doing Full table scans.
Suspecting some db parameter which is causing this issue.
In the
- Full table scans on tables in the first sub-query
PAY_PAYROLL_ACTIONS, PAY_ASSIGNMENT_ACTIONS, PAY_ACTION_INTERLOCKS
- Full table scans on tables in Second sub-query
PER_ALL_ASSIGNMENTS_F PAY_ASSIGNMENT_ACTIONS
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 29 398.80 2192.99 238706 4991924 2383 0
Fetch 1136 378.38 1921.39 0 4820511 0 1108
total 1166 777.19 4114.38 238706 9812435 2383 1108
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 41 (APPS) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 FOR UPDATE
0 PX COORDINATOR
0 PX SEND (QC (ORDER)) OF ':TQ10009' [:Q1009]
0 SORT (ORDER BY) [:Q1009]
0 PX RECEIVE [:Q1009]
0 PX SEND (RANGE) OF ':TQ10008' [:Q1008]
0 HASH JOIN (ANTI BUFFERED) [:Q1008]
0 PX RECEIVE [:Q1008]
0 PX SEND (HASH) OF ':TQ10006' [:Q1006]
0 BUFFER (SORT) [:Q1006]
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PER_ALL_ASSIGNMENTS_F' (TABLE) [:Q1006]
0 NESTED LOOPS [:Q1006]
0 NESTED LOOPS [:Q1006]
0 NESTED LOOPS [:Q1006]
0 HASH JOIN (ANTI) [:Q1006]
0 BUFFER (SORT) [:Q1006]
0 PX RECEIVE [:Q1006]
0 PX SEND (HASH) OF ':TQ10002'
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PAY_ASSIGNMENT_ACTIONS' (TABLE)
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PAY_PAYROLL_ACTIONS' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PAY_PAYROLL_ACTIONS_PK' (INDEX (UNIQUE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PAY_POPULATION_RANGES_N4' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PER_PERIODS_OF_SERVICE' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PER_PERIODS_OF_SERVICE_N3' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PER_ALL_ASSIGNMENTS_F' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PER_ASSIGNMENTS_N4' (INDEX)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PAY_ASSIGNMENT_ACTIONS_N51' (INDEX)
0 PX RECEIVE [:Q1006]
0 PX SEND (HASH) OF ':TQ10005' [:Q1005]
0 VIEW OF 'VW_SQ_1' (VIEW) [:Q1005]
0 HASH JOIN [:Q1005]
0 BUFFER (SORT) [:Q1005]
0 PX RECEIVE [:Q1005]
0 PX SEND (BROADCAST) OF ':TQ10000'
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PAY_PAYROLL_ACTIONS' (TABLE)
0 HASH JOIN [:Q1005]
0 PX RECEIVE [:Q1005]
0 PX SEND (HASH) OF ':TQ10004' [:Q1004]
0 PX BLOCK (ITERATOR) [:Q1004]
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PAY_ASSIGNMENT_ACTIONS' (TABLE) [:Q1004]
0 BUFFER (SORT) [:Q1005]
0 PX RECEIVE [:Q1005]
0 PX SEND (HASH) OF ':TQ10001'
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PAY_ACTION_INTERLOCKS' (TABLE)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'PAY_PAYROLL_ACTIONS' (TABLE) [:Q1006]
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PAY_PAYROLL_ACTIONS_PK' (INDEX (UNIQUE)) [:Q1006]
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PAY_ACTION_CLASSIFICATIONS_PK' (INDEX (UNIQUE))[:Q1006]
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PER_ASSIGNMENTS_F_PK' (INDEX (UNIQUE)) [:Q1006]
0 PX RECEIVE [:Q1008]
0 PX SEND (HASH) OF ':TQ10007' [:Q1007]
0 VIEW OF 'VW_SQ_2' (VIEW) [:Q1007]
0 FILTER [:Q1007]
0 HASH JOIN [:Q1007]
0 BUFFER (SORT) [:Q1007]
0 PX RECEIVE [:Q1007]
0 PX SEND (BROADCAST) OF ':TQ10003'
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PER_ALL_ASSIGNMENTS_F' (TABLE)
0 PX BLOCK (ITERATOR) [:Q1007]
0 TABLE ACCESS MODE: ANALYZED (FULL) OF 'PAY_ASSIGNMENT_ACTIONS' (TABLE) [:Q1007]
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
enq: KO - fast object checkpoint 32 0.02 0.12
os thread startup 8 0.02 0.19
PX Deq: Join ACK 198 0.00 0.04
PX Deq Credit: send blkd 167116 1.95 1103.72
PX Deq Credit: need buffer 327389 1.95 266.30
PX Deq: Parse Reply 148 0.01 0.03
PX Deq: Execute Reply 11531 1.95 1901.50
PX qref latch 23060 0.00 0.60
db file sequential read 108199 0.17 22.11
db file scattered read 9272 0.19 51.74
PX Deq: Table Q qref 78 0.00 0.03
PX Deq: Signal ACK 1165 0.10 10.84
enq: PS - contention 73 0.00 0.00
reliable message 27 0.00 0.00
latch free 218 0.00 0.01
latch: session allocation 11 0.00 0.00
Thanks in advance
Suresh PV

Hi,
welcome,
how is the query performing if you delete all the hints for PARALLEL, because most of the waits are related to waits on Parallel.
Herald ten Dam
http://htendam.wordpress.com
PS. Use "{code}" for showing your code and explain plans, it looks nicer

Is Index organization tables better in performance compare to normal tables

Hi,
i am using oracle 10g and my domain is on telecom.
my requirement is when 'A' party calls 'B' Party based on 'B' party number
we have to find which area the call lands based on that tariff will be applied
but the data configured in Area table is not the complete number its just a CC+NDC(4or5 digits in length)
so i have to find which one matches the nearest to 'B' party number.
i uses the following query
select max(area_code)
from ZONE_AREA
where '9888123456' like AREA_CODE||'%'
and network_id=1;
this is the structure of the table
create table ZONE_AREA(
AREA_CODE VARCHAR2(20),
AREA_NAME VARCHAR2(30) not null,
ZONE_CODE VARCHAR2(10) not null,
CALL_TYPE VARCHAR2(1) not null,
NETWORK_ID NUMBER(2),
primary key (NETWORK_ID, AREA_CODE))
the table contains around 200000 rows.
the data in table look like
AREA_CODE
98812
90020
900
9732
the hit ratio for the above query is massive since it fires for every call but my DBA complaining me
this query utilizes more CPU need to be tuned.
i thought of going for Index organization tables since i never used this but want to give a try to see any improvisation is there
Hence i created the Index organization table(IOT) for the same above structure in my development environment
with 60,000 rows in it.
create table ZONE_AREA_IOT
AREA_CODE VARCHAR2(20),
AREA_NAME VARCHAR2(30) not null,
ZONE_CODE VARCHAR2(10) not null,
CALL_TYPE VARCHAR2(1) not null,
NETWORK_ID NUMBER(2),
CONSTRAINT pk_admin_docindex1 PRIMARY KEY (NETWORK_ID, AREA_CODE))
ORGANIZATION INDEX
also the plain table (ZONE_AREA) have 60,000 rows in my development server.
now i fired the query on my plain table
select max(area_code)
from ZONE_AREA
where '9888123456' like AREA_CODE||'%'
and network_id=1;
the following is the execution plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 11 | 3 (34)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 11 | | |
| 2 | FIRST ROW | | 1 | 11 | 3 (34)| 00:00:01 |
|* 3 | INDEX RANGE SCAN (MIN/MAX)| SYS_C007738 | 1 | 11 | 3 (34)| 00:00:01 |
now i fired the query on the newly created IOT table
select max(area_code)
from ZONE_AREA_IOT
where '9888123456' like AREA_CODE||'%'
and network_id=1;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 25 | 2 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 25 | | |
| 2 | FIRST ROW | | 21 | 525 | 2 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN (MIN/MAX)| PK_ADMIN_DOCINDEX1 | 21 | 525 | 2 (0)| 00:00:01 |
both tables have similar record count
but the plans differ don't under stand the Rows column in the above plans for normal table its shows 11 bytes
for IOT table it shows 525 bytes why this difference ?
also CPU cost shows 3 in normal table and for IOT it shows 2
for the above scenario is IOT table is advisable will it cut down the CPU cost is any overheads there for using IOT
please respond
regards
naveen

I think you are deviating from the real problem.
I'm also in Telecom domain and what you are talking about is what is called "most matching" algorithm.
Practically suppose that party A calls party B and you want to know which is the tariff to apply.
Usually tariff tables are based on this "most matching" criteria where the correct tariff is the most matching with the called number.
Let me give you an example.
Suppose that I have a tariff table in this way:
WITH mytariff AS
   SELECT '90123' destination, 1.5 tariff_per_min FROM DUAL UNION ALL
   SELECT '9012' destination, 1.6 tariff_per_min FROM DUAL UNION ALL
   SELECT '901'   destination, 1.7 tariff_per_min FROM DUAL UNION ALL
   SELECT '90'    destination, 1.8 tariff_per_min FROM DUAL UNION ALL
   SELECT '55123' destination, 1.0 tariff_per_min FROM DUAL UNION ALL
   SELECT '5512' destination, 1.1 tariff_per_min FROM DUAL UNION ALL
   SELECT '551'   destination, 1.2 tariff_per_min FROM DUAL UNION ALL
   SELECT '55'    destination, 1.3 tariff_per_min FROM DUAL
SELECT * FROM mytariff;
DESTINATION          TARIFF_PER_MIN
90123                           1.5
9012                            1.6
901                             1.7
90                              1.8
55123                             1
5512                            1.1
551                             1.2
55                              1.3
{code}
Correct me if I'm wrong:
{code}
if party A dials 901234567 then it will match destination 90123 and tariff_per_min 1.5
if party A dials 901244567 then it will match destination 9012 and tariff_per_min 1.6
if party A dials 901344567 then it will match destination 901   and tariff_per_min 1.6
if party A dials 551244567 then it will match destination 5512 and tariff_per_min 1.1
etc.
{code}
Confirm if this is your criteria in finding the tariff.
The billing/rating systems I know usually store this information in database tables but the rating engine (generally a c++ program in Unix) is normally reading this information once, putting them in memory and rating the calls by reading information in memory.
I'm not saying that this is the only approach but it seems the most used.
In your case, It looks that you are using to do the same thing SQL or PL/SQL and definitely I understand that applying this algorithm by reading the tariff table for each call records is going to affect your performances heavily.
I have a couple of questions for your:
1) Are you using a SQL statement or a PL/SQL procedure to rate your calls?
2) Could you show us how you assign the tariff to your calls?
I don't think using IOT will solve your problem. IOT has the advantage to read the data together with the index and it is suitable especially if you read your data always with a certain key.
If your data about tariff is static, or doesn't change so often, which I suppose it the case, you could consider a different approach like loading them in a collection in PL/SQL and them retrieving them from collection. It might not be the optimal solution but it is worth considering it.
In order to evaluate your problem please give the details mentioned above.
Regards.
Al

ORA-01445: cannot select ROWID from, or sample, a join view without a key-p

Hi All,
I am facing issue with one sql query. It is giving me error:
ORA-01445: cannot select ROWID from, or sample, a join view without a key-preserved table
I am not getting any clue to solve this. On internet, i didn't find proper reason for this error and troubleshooting way and solution for this error. Everywhere i saw one sentence, "Key preserved means the row from the base table will appear AT MOST ONCE in the output view on that table" but it didn't solve my problem.
I have 1099 columns in one select query. so avoiding the actual column list in select clause. Instead I am trying to select ROWIDs from all tables in join. My understanding is ROWID is a unique identifier in table not in database. But though I remove ROWIDs, I get same error. So please don't bother about these ROWIDs.
SELECT
TO_DATE(FACT.BUS_DATE_FKID,'YYYYMMDD')
,FACT.ROWID AS ABC1
,FACT_ADJ.ROWID AS ABC2
,DIM_SEC.ROWID AS ABC3
,DIM_SEC_ADJ.ROWID AS ABC4
,DIS_CAT.ROWID AS ABC5
,CTRY.ROWID AS ABC6
,BCP.ROWID AS ABC7
,STAGE.ROWID AS ABC8
FROM FACT_POSITION FACT
LEFT JOIN FACT_POSITION_ADJ FACT_ADJ ON FACT.POSITION_PKID = FACT_ADJ.POSITION_FKID
LEFT JOIN DIM_SOURCE_SYSTEM SOURCE ON FACT.SOURCE_SYSTEM_FKID = SOURCE.SOURCE_SYSTEM_PKID
LEFT JOIN DIM_SECURITY DIM_SEC ON FACT.SUBSYS_SECURITY_FKID = DIM_SEC.SECURITY_PKID
LEFT JOIN DIM_SECURITY_ADJ DIM_SEC_ADJ ON FACT.SUBSYS_SECURITY_FKID = DIM_SEC_ADJ.SECURITY_PKID
LEFT JOIN DIM_DISCLOSURE_CATEGORY DIS_CAT ON FACT.DISCLOSURE_CATEGORY_FKID = DIS_CAT.DISCLOSURE_CATEGORY_PKID
LEFT JOIN COUNTRY_REFERENCE CTRY ON CTRY.DESCRIPTION = DIM_SEC.ISSUER_COUNTRY
LEFT JOIN BUSINESS_CLOSE_PERIOD BCP
ON BCP.BUSINESS_CLOSE_DATE = ADD_MONTHS(TRUNC(TO_DATE(FACT.BUS_DATE_FKID,'YYYYMMDD'),'MM'), 1) -1
AND BCP.IS_LOCKED='Y' AND BCP.IS_ACTIVE='Y'
LEFT JOIN GUI_STAGING STAGE ON
FACT.POSITION_PKID=STAGE.POSITION_PKID
AND STAGE.IS_ACTIVE='Y'
AND STAGE.STATUS_ID IN(12,8,1,2,3,4,5)
WHERE FACT.POSITION_PKID=64524374;
While trying to sort this error, I found interesting things that made me more confused.
if I remove TO_DATE function from select clause, same join query works.
If I remove any table from join and keep TO_DATE function in select clause, query works.
That tells, there is no problem in query.
Then please anyone help me to sort out the error. FYI. I have googled a lot for this error. but didn't get solution/clue. That is why I am posting this problem to forum.
Thanks in advance. waiting for reply ASAP.
Pravin Pujari
[email protected]

I think i got the solution. The syntax i was using (ANSI syntax) doesn't work in the oracle database version i am using.
When i updated my query with older oracle syntax, it worked.
SELECT
TO_DATE(FACT.BUS_DATE_FKID,'YYYYMMDD')
,FACT.ROWID AS ABC1
,FACT_ADJ.ROWID AS ABC2
,SOURCE.ROWID AS ABC3
,DIM_SEC.ROWID AS ABC4
,DIM_SEC_ADJ.ROWID AS ABC5
,DIS_CAT.ROWID AS ABC6
,CTRY.ROWID AS ABC7
,BCP.ROWID AS ABC8
,STAGE.ROWID AS ABC8
FROM [email protected] FACT
,[email protected] FACT_ADJ
,[email protected] SOURCE
,[email protected] DIM_SEC
, [email protected] DIM_SEC_ADJ
, [email protected] DIS_CAT
, GUI.COUNTRY_REFERENCE CTRY
, GUI.BUSINESS_CLOSE_PERIOD BCP
, GUI.GUI_STAGING STAGE
WHERE FACT.POSITION_PKID=64517140
AND FACT_ADJ.POSITION_FKID(+) = FACT.POSITION_PKID
AND SOURCE.SOURCE_SYSTEM_PKID=FACT.SOURCE_SYSTEM_FKID
AND DIM_SEC.SECURITY_PKID=FACT.SUBSYS_SECURITY_FKID
AND DIM_SEC_ADJ.SECURITY_PKID(+)=DIM_SEC.SECURITY_PKID
AND FACT.DISCLOSURE_CATEGORY_FKID = DIS_CAT.DISCLOSURE_CATEGORY_PKID
AND CTRY.DESCRIPTION = DIM_SEC.ISSUER_COUNTRY
AND BCP.BUSINESS_CLOSE_DATE = ADD_MONTHS(TRUNC(TO_DATE(FACT.BUS_DATE_FKID,'YYYYMMDD'),'MM'), 1) -1
AND BCP.IS_ACTIVE='Y'
AND FACT.POSITION_PKID=STAGE.POSITION_PKID
AND STAGE.IS_ACTIVE='Y'
AND STAGE.STATUS_ID IN(12,8,1,2,3,4,5);

Rowid in IOT table

Similar Messages

Maybe you are looking for