Why slow DML in Index organized tables

I learned that ITO system was not suitable for tables that have a high volume of DML operations.

I want to know that:

1.) why DML operations are slow when we have data and indexes in the same place for ITO?
2.) why we take extra precautions for fragmentation to ITO that pile of paintings organized?

It's as long as your application does not change for the PK values that inspire you the IOT.

If you have an application that actually modifies the values of primary key - Ouch!

Here's how to think this through:
Think of an Index on a column usually.
What happens when you update the value of this column for a line or set of lines?
The update to the line goes into the table block (and if the line does not expand or PCTFREE is adequate, there is no chaining line)
However, the update of the index entry is not just an update. Because an Index is a Structure y (unlike a heap table), in order to change the value of an Index key (even when not unique), you have to 'remove' of the 'location' (IE block) he currently resides to and "insert" in the new "place" (block) corresponding to the new value. So, for example, if change 'Aman' (probably at the head of the Index tree) to "Hemant" (somewhere in the middle), you will find that "Hemant" belongs to another block - so that the index of "Aman" entry should be removed and a new entry for "Hemant" (pointing to the same ROWID) inserted in the correct index leaf block where 'Hemant' belongs.

Now, instead of an Index on a single column, think an whole table-ITO is an ordered structure. If you change the value of the key to the order (ie the Index key) then the line should be moved to the correct location that he must belong.

As it is, it is very bad design to change the values for the PK building. an IOT in such a severely design adds to the problem. Now, instead of simply delete and insert for the column values, the entire row should be deleted and inserted.

However, if you do not change the values of the PK, then you should not have problems with updates. However, if the size of the line is large (or increases with updates), you will need to handle the overflow.

Hemant K Collette
http://hemantoracledba.blogspot.com

Tags: Database

Similar Questions

Delete Performance index organized Tables
Hello

We are experiencing some performance problems with one of our tables.

We have a table (test), which contains 9 columns:

A number (10) not null not pk,.
B number (10),
C number (10),
D number (10),
E number (10),
F varchar2 (30),
F varchar2 (2),
G varchar2 (2),
H varchar2 (250).

The table test is an ITO (Index Organized Table) in configuration of default ITO.
All columns are often necessary for we can not all overflows.

The table has currently 8 m records, which is roughly 1/2 years of a data value, so insignificant.
Inserts and updates are fine, but it takes 40 + seconds to delete a single line!

(remove test where a = 3043 ;))

If I convert this table in a standard table, deletes are only 0.5 of a second?

No idea why the delete statement takes an excessively long time on the IOT, or what I could do wrong?

Thank you
Victoria

Oracle Enterprise version 10.2.0.1.0
Oracle XE version 10.2.0.1.0
It seems as if the PK on this table of ITO is referenced by a FK on a child table (big enough) but the FK does not have an associated index.

Deleting a line in this table, Oracle is required to perform a FTS on the child table to make sure that there is no matching FK.

Find out if you have indeed a FK that refers to this table, and if CF is indexed.

Just a guess, of course. A long track during the delete operation should be noted where Pio come just to be sure.

See you soon

Richard Foote
http://richardfoote.WordPress.com/

Partitioning or an index organized table. Suggestion required.

Hi gurus,
We decided to perfomance increase in customer table that has more than 100 million records
{code}
customer_id number,
cust_name varchar,
Date of Applied_date,
City varchar (100)
{code}
This is the structure of the customer table.
We decided to composite partition the table based on date (range) applied and customer_id (hash).
I am confused to go with table index (where tables and indexes are stored together) for better performance.
Please suggest what we I'm going? for best performance.
Please answer
Supersen

If the query predicate (WHERE clause) include the Partition key column, Oracle can make the size of Partition - that is to say identify the target Partition. Otherwise, he would have to do a full Table Scan because he doesn't know what Partition the target Row (s) is in.

For example, if you are partitioning by APPLIED_DATE but your request is on the table by CITY, Oracle cannot identify the target Partition and do a Scan of Table full - even if you subpartition by CUSTOMER_ID and integrate CUSTOMER_ID in your query, Oracle cannot identify the Subpartition because it cannot identify the Partition.

Hemant K Collette

Index organized Tables
What is logical rowid in IOT? are they kept physically somwhere like physical rowId

What are secondary indexes?

what he meant by leaves block splits? When and how it happens?

and the primary key for a table in index constraint cannot be abandoned, delayed or off, is this true, if yes then Y

How overflow works? how the two clauses are implemented PCTTHRESHOLD and INCLUDING.how they work?

Published by: Juhi on October 22, 2008 13:09
I'm sort of tempted to simply point you in the direction of the official documentation (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 ROWID not is not physically stored. I don't know why you would think they were. Certainly the ROWID data type can store a rowid if you choose to do, but if you do something like "select rowid from scott.emp", for example, you will see the ROWID that are generated on the fly. ROWID is a pseudo-column, not physically stored anywhere, but calculated each time as needed.

The difference between a physical rowid and logic used with IOT boils down to a bit of relational database theory. It is a rule in melting of relational databases that a line, once inserted into a table, must never move. In other words, the identifier that is assigned at the time of his first insertion, must be the rowid he "keeps" for ever and ever. If you ever want to change the assigned lines in an ordinary table ROWID, you must export them, truncate the table, and then reinsert them: Insert charges, fees rowid. (Oracle bend this rule for various purposes of maintenance and management, according to which 'allow the movement of line"allows lines without a table, but the general case is still valid for most).

This rule is obviously hopeless for the index structures. It was true, an index entry for "Bob" which is updated to "Robert" would find next to the entries for 'Adam' and 'Charlie', even though she now has a value of 'R '. Effectively, 'line' a 'b' in an index must be allowed to "move" a sort of 'r' of the block if it's the kind 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 do not change the principle: 'lines' in an index must be allowed to move if their value is changed; rows of a table do not move, no matter what happens to their values)

An IOT is, at the end of the day, simply an index with columns much more in it that a 'normal' index would - he, too, has thus allow its entires (his 'rows', if you like) to move. Therefore, an IOT cannot use a standard ROWID, which is assigned only once and forever. Instead, one must use something that takes into account that its lines may wander. It's the logical rowid. It is not more 'physical' as a physical rowid - or are physically stored anywhere. But a 'physical' rowid is invariable; a logic is not. Logic, it is actually built in part of the primary key of the ITO - and this is the main reason why you can never get rid of the primary key on the IOT constraint. Be allowed to do would be to you to destroy an organizing principle for its content which has an IOT.

(See the section called "The virtual ROWID" and continued on this page: http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT1845)

IOT so their data stored inside in the primary key order. But they only contain the primary key, but all the other columns in the definition of 'table' too. Therefore, just as with an ordinary table, you might sometimes find data on columns that are NOT part of the first key - and in this case, you might well these columns non-primary keys are indexed. Therefore, you create ordinary index on those columns - at this point, you create an index in an index, really, but it's a secondary question, too! These additional indices are called 'secondary index', simply because they are "subsidiary clues" in the main proceedings, which is the 'picture' himself laid out in the primary key order.

Finally, a split block of sheets is simply what happens when you have to make room for the new data in an index block which is already filled to overflowing with the existing data. Imagine an index block may not contain four entries, for example. Fill you with entries for Adam, Bob, Charlie, David. Now, you insert a new record of 'Brian '. If it's a table, you can take Brian to a new block you like: data from a table have no positional sense. But the entries of an index MUST have positional significance: you can't just throw MC Bean and Brian in the middle of a lot of Roberts, bristling. Brian DOIT pass between the existing entries for Bob and Charlie. Still you can not just put him in the middle of these two, because then you'd have five entries in a block, not four, which we imagined for the moment to be maximally allowed. So what to do? What you do is: get an empty block. Move Charlie and David entries in the new block. Now you have two blocks: Adam-Bob and Charlie David. Each has only two entries, so each has two 'spaces' to accept new entries. Now you have room to add in the entry for Brian... and if you end up with Adam-Bob-Brian and Charlie David.

The process of moving the index entries in a single block in a new one so that there is room to allow new entries to be inserted in the middle of existing ones is called a split of block. They occur for other reasons too, so it's just a brilliant of them treatment, but they give you the basic idea. It's because of splits of block that indexes (and thus IOT) see their 'lines' move: Charlie and David started in a single block and ended up in a completely different block due to a new (and completely foreign to them) Insert.

Very well, infinity is simply a means of segregation of data in a separate table segment that would not reasonably be stored in the main segment of the ITO himself. Suppose that you are creating an IOT containing four columns: one, a digital 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 of data type - so it could be stored whole, multi-gigabyte-size monsters DVD movies. Do you really want your index segment (because that's what an IOT really is) to ball to the huge dimensions, every time that you add a new line? Probably not. You probably want 1 to 3 columns, stored in the IOT, but column 4 can be struck off the coast to a segment on its own (the overflow segment, actually) and a link (in fact, a physical rowid pointer) can bind to the other. Left to himself, an IOT will cut each column after the a primary key when a record that threatens to consume more than 50% of a block is inserted. However, to keep the main IOT small and compact and yet still contain data of non-primary key, you can change these default settings. INCLUDE, for example, to specify what last non-primary key column should be the point where a record is split between "keep in IOT" and "out to overflow segment." You could say "INCLUDE COL3" in the previous example, so that COL1, COL2 and COL3 remain in the IOT and only COL4 overflows. And PCTTHRESHOLD can be set at, say, 5 or 10 so that you try to assure an IOT block always contains 10 to 20 saves - instead of the 2 you would end up with default if 50% of kicks.

Why full when I index the table scan
Can someone quickly tell me why this statement will generate a full table scan if RECEIPT_NO for both tables have a unique index.

Select * from agency_ledger where a.RECEIPT_NO in (select receipt_no from temp)

concerning
Hello

Two reason I can think
(1) statistics are not collected or are at a standstill.
(2) oracle considers the hash join full table scan more appropriate than the nested loop + scan small index.

Post your explain plain and let us know stats is collected or not.
In addition, let us know what is the percentage of rows are expected in output compared to the total number of lines.

Concerning
Anurag Tibrewal.

Table slow access by index rowid

Hi all
10.2.0.1
I have two queries that do the same thing but written in a different way.
A quick index is scan and accesses the table with rowid, the other performs a full table scan.

Partial TKPROF for query performing index scan Q_I:

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.01       0.01          0          0          2           0
Execute      1      0.00       0.00          0          0         13           0
Fetch        5      0.14       0.69         13      24252          0          53
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        7      0.15       0.70         13      24252         15          53

Misses in library cache during parse: 1

Rows     Row Source Operation
-------  ---------------------------------------------------
     53  SORT GROUP BY (cr=24252 pr=13 pw=0 time=692418 us)
   1103   HASH JOIN  (cr=24252 pr=13 pw=0 time=691345 us)
    222    TABLE ACCESS FULL HOD_USER (cr=5 pr=0 pw=0 time=42 us)
   1100    VIEW  (cr=24247 pr=13 pw=0 time=690198 us)
  1100     HASH GROUP BY (cr=24247 pr=13 pw=0 time=689097 us)
  36496      TABLE ACCESS BY INDEX ROWID DDO_ALT (cr=24247 pr=13 pw=0 time=109536 us)
  36496       INDEX FULL SCAN PK_DDOALT (cr=2226 pr=6 pw=0 time=36532 us)(object id 117105)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
     53   SORT (GROUP BY)
   1103    HASH JOIN
    222     TABLE ACCESS   MODE: ANALYZED (FULL) OF 'HOD_USER' (TABLE)
   1100     VIEW
   1100      HASH (GROUP BY)
  36496       TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF
                  'DDO_ALT' (TABLE)
  36496        INDEX   MODE: ANALYZED (FULL SCAN) OF 'PK_DDOALT'
                   (INDEX (UNIQUE))

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       5        0.00          0.00
  db file sequential read                        13        0.09          0.55
  SQL*Net message from client                     5        0.00          0.00

Query run TKProf full table SCAN Q_f:

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          4           0
Execute      1      0.00       0.00          0          0         13           0
Fetch        5      0.15       0.39         17       2023          0          53
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        7      0.15       0.40         17       2023         17          53

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS


Rows     Row Source Operation
-------  ---------------------------------------------------
     53  SORT GROUP BY NOSORT (cr=2023 pr=17 pw=0 time=398252 us)
    648   VIEW  (cr=2023 pr=17 pw=0 time=399497 us)
    648    SORT GROUP BY (cr=2023 pr=17 pw=0 time=398845 us)
  37537     HASH JOIN  (cr=2023 pr=17 pw=0 time=564274 us)
    222      TABLE ACCESS FULL HOD_USER (cr=5 pr=0 pw=0 time=267 us)
  36679      TABLE ACCESS FULL DDO_ALT (cr=2018 pr=17 pw=0 time=37 us)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
     53   SORT (GROUP BY NOSORT)
    648    VIEW
 648     SORT (GROUP BY)
  37537      HASH JOIN
    222       TABLE ACCESS   MODE: ANALYZED (FULL) OF 'HOD_USER'
                  (TABLE)
  36679       TABLE ACCESS   MODE: ANALYZED (FULL) OF 'DDO_ALT' (TABLE)



Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                       5        0.00          0.00
  db file sequential read                        15        0.06          0.18
  db file scattered read                          1        0.06          0.06
  SQL*Net message from client                     5        0.00          0.00

Why 24247 complies for access by index rowid table, for access to the index, is 2226.
Why the full table scan is faster in this case?

Hisoka says:
Why the full table scan is faster in this case?

As P. Forstmann suggested, it would help if you can post queries and their results of EXPLAIN PLAN.
Now, I know guess is bad, but I want to have a go on this one, so we'll see ;)
My comments (in no particular order of relevance/importance)
(1) you use a non patched (10.2.0.1) version which, I believe, is known to contain many bugs (and therefore can throw 'surprises')
(2) the name of the index, it is clear that PK_DDOALT is a unique index (supporting the primary key constraint) table DDO_ALT so
factor clustered index is (probably) not the issue.
(3) the TkProf output tells 36496 lines are currently extracted from table DDO_ALT in the query that uses the index analysis while
36679 lines are currently extracted a DDO_ALT table in the query that uses the full table scan.
It seems that the DDO_ALT table has about 36679 lines. Now, it will be slower (such as oracle to access most of these lines using the index
you will need to visit a (table) block at the same time (and will eventually visit same block several times) compared to the full table scan.
who reads several blocks at a time (and eventually NOT have to visit same block several times). This can be confirmed
by the numbers "cr" TkProf. 24247 consistent gets for the query using access indexed for 36496 lines (with the exception of consistent gets for the reading of the index)
2018 coherent vs gets to access 36679 lines.
(4) the operation "line Source" indicates that the query using an indexed access is written so that it forces the use of the index (most likely
using an indicator of index). It's that reason optimizer uses "INDEX FULL SCAN" and not "INDEX RANGE SCAN". A FULL INDEX SCAN bed set
structure of the index, a block at a time, which is not an efficient operation compared to the optimizer to choose naturally "INDEX RANGE SCAN", which
that will show some of the index blocks.
(5) Finally, it appears this query that uses access indexed, is written to 'say' oracle how to process the query. Maybe it's OK if you think that
your knowledge of the data schemas is better than knowledge of the optimizer. But this certainly isn't the case here.
Your queries are probably something like
Query using index:

SELECT 
FROM HOD_USER, (SELECT /*+ INDEX(DDO_ALT PK_DDOALT) */ 
                             FROM DDO_ALT
                            GROUP BY ) DD
WHERE HOD_USER. = DD.
GROUP BY 
ORDER BY

The query using full table scan:

SELECT 
 FROM (SELECT 
             FROM HOD_USER, DDO_ALT
          WHERE HOD_USER. = DDO_ALT.
             GROUP BY 
             ORDER BY )
GROUP BY 
ORDER BY

Published by: user503699 on August 21, 2010 18:47 added ORDER BY clauses for both queries

Why the optimizer ignores Index Fast full Scan when much lower cost?

Summary (tracking details below) - to improve the performance of a query on more than one table, I created an index on a table that included all the columns referenced in the query. With the new index in place the optimizer is still choosing a full Table Scan on an Index fast full scan. However, by removing the one query tables I reach the point where the optimizer suddenly use the Index Fast Full Scan on this table. And 'Yes', it's a lot cheaper than the full Table Scan it used before. By getting a test case, I was able to get the motion down to 4 tables with the optimizer still ignoring the index and table of 3, it will use the index.

So why the optimizer not chooses the Index Fast Full Scan, if it is obvious that it is so much cheaper than a full Table Scan? And why the deletion of a table changes how the optimizer - I don't think that there is a problem with the number of join permutations (see below). The application is so simple that I can do, while remaining true to the original SQL application, and it still shows this reversal in the choice of access path. I can run the queries one after another, and he always uses a full Table Scan for the original query and Index fast full scan for the query that is modified with a table less.

Watching trace 10053 output for the two motions, I can see that for the original query 4 table costs alone way of ACCESS of TABLE UNIQUE section a full Table Scan. But for the modified query with a table less, the table now has a cost for an Index fast full scan also. And the end of the join cost 10053 does not end with a message about exceeding the maximum number of permutations. So why the optimizer does not cost the IFFS for the first query, when it does for the second, nearly identical query?

This is potentially a problem to do with OUTER joins, but why? The joins between the tables do not change when the single extra table is deleted.

It's on 10.2.0.5 on Linux (Oracle Enterprise Linux). I did not define special settings I know. I see the same behavior on 10.2.0.4 32-bit on Windows (XP).

Thank you
John
Blog of database Performance

DETAILS
I've reproduced the entire scenario via SQL scripts to create and populate the tables against which I can then run the queries. I've deliberately padded table so that the length of the average line of data generated is similar to that of the actual data. In this way the statistics should be similar on the number of blocks and so forth.

System - uname - a

Linux mysystem.localdomain 2.6.32-300.25.1.el5uek #1 SMP Tue May 15 19:55:52 EDT 2012 i686 i686 i386 GNU/Linux

Database - v$ version

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Prod
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

Original query (complete table below details):

SELECT 
    episode.episode_id , episode.cross_ref_id , episode.date_required , 
    product.number_required , 
    request.site_id 
FROM episode 
LEFT JOIN REQUEST on episode.cross_ref_id = request.cross_ref_id 
     JOIN product ON episode.episode_id = product.episode_id 
LEFT JOIN product_sub_type ON product.prod_sub_type_id = product_sub_type.prod_sub_type_id 
WHERE (
        episode.department_id = 2
    and product.status = 'I'
      ) 
ORDER BY episode.date_required
;

Execution of display_cursor after the execution plan:

SQL_ID  5ckbvabcmqzw7, child number 0
-------------------------------------
SELECT     episode.episode_id , episode.cross_ref_id , episode.date_required ,
product.number_required ,     request.site_id FROM episode LEFT JOIN REQUEST on
episode.cross_ref_id = request.cross_ref_id      JOIN product ON episode.episode_id =
product.episode_id LEFT JOIN product_sub_type ON product.prod_sub_type_id =
product_sub_type.prod_sub_type_id WHERE (         episode.department_id = 2 and
product.status = 'I'       ) ORDER BY episode.date_required

Plan hash value: 3976293091

-----------------------------------------------------------------------------------------------------
| Id  | Operation             | Name                | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                     |       |       |       | 35357 (100)|          |
|   1 |  SORT ORDER BY        |                     | 33333 |  1920K|  2232K| 35357   (1)| 00:07:05 |
|   2 |   NESTED LOOPS OUTER  |                     | 33333 |  1920K|       | 34879   (1)| 00:06:59 |
|*  3 |    HASH JOIN OUTER    |                     | 33333 |  1822K|  1728K| 34878   (1)| 00:06:59 |
|*  4 |     HASH JOIN         |                     | 33333 |  1334K|       |   894   (1)| 00:00:11 |
|*  5 |      TABLE ACCESS FULL| PRODUCT             | 33333 |   423K|       |   103   (1)| 00:00:02 |
|*  6 |      TABLE ACCESS FULL| EPISODE             |   299K|  8198K|       |   788   (1)| 00:00:10 |
|   7 |     TABLE ACCESS FULL | REQUEST             |  3989K|    57M|       | 28772   (1)| 00:05:46 |
|*  8 |    INDEX UNIQUE SCAN  | PK_PRODUCT_SUB_TYPE |     1 |     3 |       |  0   (0)|          |
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("EPISODE"."CROSS_REF_ID"="REQUEST"."CROSS_REF_ID")
   4 - access("EPISODE"."EPISODE_ID"="PRODUCT"."EPISODE_ID")
   5 - filter("PRODUCT"."STATUS"='I')
   6 - filter("EPISODE"."DEPARTMENT_ID"=2)
   8 - access("PRODUCT"."PROD_SUB_TYPE_ID"="PRODUCT_SUB_TYPE"."PROD_SUB_TYPE_ID")

Updated the Query:

SELECT 
    episode.episode_id , episode.cross_ref_id , episode.date_required , 
    product.number_required , 
    request.site_id 
FROM episode 
LEFT JOIN REQUEST on episode.cross_ref_id = request.cross_ref_id 
     JOIN product ON episode.episode_id = product.episode_id 
WHERE (
        episode.department_id = 2
    and product.status = 'I'
      ) 
ORDER BY episode.date_required
;

Execution of display_cursor after the execution plan:

SQL_ID  gbs74rgupupxz, child number 0
-------------------------------------
SELECT     episode.episode_id , episode.cross_ref_id , episode.date_required ,
product.number_required ,     request.site_id FROM episode LEFT JOIN REQUEST on
episode.cross_ref_id = request.cross_ref_id      JOIN product ON episode.episode_id =
product.episode_id WHERE (         episode.department_id = 2     and product.status =
'I'       ) ORDER BY episode.date_required

Plan hash value: 4250628916

----------------------------------------------------------------------------------------------
| Id  | Operation              | Name        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |             |       |       |       | 10515 (100)|          |
|   1 |  SORT ORDER BY         |             | 33333 |  1725K|  2112K| 10515   (1)| 00:02:07 |
|*  2 |   HASH JOIN OUTER      |             | 33333 |  1725K|  1632K| 10077   (1)| 00:02:01 |
|*  3 |    HASH JOIN           |             | 33333 |  1236K|       |   894   (1)| 00:00:11 |
|*  4 |     TABLE ACCESS FULL  | PRODUCT     | 33333 |   325K|       |   103   (1)| 00:00:02 |
|*  5 |     TABLE ACCESS FULL  | EPISODE     |   299K|  8198K|       |   788   (1)| 00:00:10 |
|   6 |    INDEX FAST FULL SCAN| IX4_REQUEST |  3989K|    57M|       |  3976   (1)| 00:00:48 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("EPISODE"."CROSS_REF_ID"="REQUEST"."CROSS_REF_ID")
   3 - access("EPISODE"."EPISODE_ID"="PRODUCT"."EPISODE_ID")
   4 - filter("PRODUCT"."STATUS"='I')
   5 - filter("EPISODE"."DEPARTMENT_ID"=2)

Creating the table and Population:
1 create tables
2. load data
3 create indexes
4. collection of statistics

--
-- Main table
--
create table episode (
episode_id number (*,0),
department_id number (*,0),
date_required date,
cross_ref_id varchar2 (11),
padding varchar2 (80),
constraint pk_episode primary key (episode_id)
) ;
--
-- Product tables
--
create table product_type (
prod_type_id number (*,0),
code varchar2 (10),
binary_field number (*,0),
padding varchar2 (80),
constraint pk_product_type primary key (prod_type_id)
) ;
--
create table product_sub_type (
prod_sub_type_id number (*,0),
sub_type_name varchar2 (20),
units varchar2 (20),
padding varchar2 (80),
constraint pk_product_sub_type primary key (prod_sub_type_id)
) ;
--
create table product (
product_id number (*,0),
prod_type_id number (*,0),
prod_sub_type_id number (*,0),
episode_id number (*,0),
status varchar2 (1),
number_required number (*,0),
padding varchar2 (80),
constraint pk_product primary key (product_id),
constraint nn_product_episode check (episode_id is not null) 
) ;
alter table product add constraint fk_product 
foreign key (episode_id) references episode (episode_id) ;
alter table product add constraint fk_product_type 
foreign key (prod_type_id) references product_type (prod_type_id) ;
alter table product add constraint fk_prod_sub_type
foreign key (prod_sub_type_id) references product_sub_type (prod_sub_type_id) ;
--
-- Requests
--
create table request (
request_id number (*,0),
department_id number (*,0),
site_id number (*,0),
cross_ref_id varchar2 (11),
padding varchar2 (80),
padding2 varchar2 (80),
constraint pk_request primary key (request_id),
constraint nn_request_department check (department_id is not null),
constraint nn_request_site_id check (site_id is not null)
) ;
--
-- Activity & Users
--
create table activity (
activity_id number (*,0),
user_id number (*,0),
episode_id number (*,0),
request_id number (*,0), -- always NULL!
padding varchar2 (80),
constraint pk_activity primary key (activity_id)
) ;
alter table activity add constraint fk_activity_episode
foreign key (episode_id) references episode (episode_id) ;
alter table activity add constraint fk_activity_request
foreign key (request_id) references request (request_id) ;
--
create table app_users (
user_id number (*,0),
user_name varchar2 (20),
start_date date,
padding varchar2 (80),
constraint pk_users primary key (user_id)
) ;

prompt Loading episode ...
--
insert into episode
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 2,
    sysdate + mod (r, 14),
    to_char (r, '0000000000'),
    'ABCDEFGHIJKLMNOPQRSTUVWXYZ' || to_char (r, '000000')
  from generator g
where g.r <= 300000
/
commit ;
--
prompt Loading product_type ...
--
insert into product_type
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 
       to_char (r, '000000000'),
       mod (r, 2),
       'ABCDEFGHIJKLMNOPQRST' || to_char (r, '000000')
  from generator g
where g.r <= 12
/
commit ;
--
prompt Loading product_sub_type ...
--
insert into product_sub_type
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 
       to_char (r, '000000'),
       to_char (mod (r, 3), '000000'),
       'ABCDE' || to_char (r, '000000')
  from generator g
where g.r <= 15
/
commit ;
--
prompt Loading product ...
--
-- product_id prod_type_id prod_sub_type_id episode_id padding 
insert into product
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, mod (r, 12) + 1, mod (r, 15) + 1, mod (r, 300000) + 1,
       decode (mod (r, 3), 0, 'I', 1, 'C', 2, 'X', 'U'),
       dbms_random.value (1, 100), NULL
  from generator g
where g.r <= 100000
/
commit ;
--
prompt Loading request ...
--
-- request_id department_id site_id cross_ref_id varchar2 (11) padding 
insert into request
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, mod (r, 4) + 1, 1, to_char (r, '0000000000'),
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz01234567890123456789' || to_char (r, '000000'),
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789012345678' || to_char (r, '000000')
  from generator g
where g.r <= 4000000
/
commit ;
--
prompt Loading activity ...
--
-- activity activity_id user_id episode_id request_id (NULL) padding 
insert into activity
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, mod (r, 50) + 1, mod (r, 300000) + 1, NULL, NULL
  from generator g
where g.r <= 100000
/
commit ;
--
prompt Loading app_users ...
--
-- app_users user_id user_name start_date padding 
insert into app_users
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, 
       'User_' || to_char (r, '000000'),
       sysdate - mod (r, 30),
       'ABCDEFGHIJKLMNOPQRSTUVWXYZ' || to_char (r, '000000')
  from generator g
where g.r <= 1000
/
commit ;
--

prompt Episode (1)
create index ix1_episode_cross_ref on episode (cross_ref_id) ;
--
prompt Product (2)
create index ix1_product_episode on product (episode_id) ;
create index ix2_product_type on product (prod_type_id) ;
--
prompt Request (4)
create index ix1_request_site on request (site_id) ;
create index ix2_request_dept on request (department_id) ;
create index ix3_request_cross_ref on request (cross_ref_id) ;
-- The extra index on the referenced columns!!
create index ix4_request on request (cross_ref_id, site_id) ;
--
prompt Activity (2)
create index ix1_activity_episode on activity (episode_id) ;
create index ix2_activity_request on activity (request_id) ;
--
prompt Users (1)
create unique index ix1_users_name on app_users (user_name) ;
--
prompt Gather statistics on schema ...
--
exec dbms_stats.gather_schema_stats ('JB')

10053 sections - original query

***************************************
SINGLE TABLE ACCESS PATH
  -----------------------------------------
  BEGIN Single Table Cardinality Estimation
  -----------------------------------------
  Table: REQUEST  Alias: REQUEST
    Card: Original: 3994236  Rounded: 3994236  Computed: 3994236.00  Non Adjusted: 3994236.00
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: TableScan
    Cost:  28806.24  Resp: 28806.24  Degree: 0
      Cost_io: 28738.00  Cost_cpu: 1594402830
      Resp_io: 28738.00  Resp_cpu: 1594402830
******** Begin index join costing ********
  ****** trying bitmap/domain indexes ******
  Access Path: index (FullScan)
    Index: PK_REQUEST
    resc_io: 7865.00  resc_cpu: 855378926
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 7901.61  Resp: 7901.61  Degree: 0
  Access Path: index (FullScan)
    Index: PK_REQUEST
    resc_io: 7865.00  resc_cpu: 855378926
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 7901.61  Resp: 7901.61  Degree: 0
  ****** finished trying bitmap/domain indexes ******
******** End index join costing ********
  Best:: AccessPath: TableScan
         Cost: 28806.24  Degree: 1  Resp: 28806.24  Card: 3994236.00  Bytes: 0
***************************************

10053 - updated the Query

***************************************
SINGLE TABLE ACCESS PATH
  -----------------------------------------
  BEGIN Single Table Cardinality Estimation
  -----------------------------------------
  Table: REQUEST  Alias: REQUEST
    Card: Original: 3994236  Rounded: 3994236  Computed: 3994236.00  Non Adjusted: 3994236.00
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: TableScan
    Cost:  28806.24  Resp: 28806.24  Degree: 0
      Cost_io: 28738.00  Cost_cpu: 1594402830
      Resp_io: 28738.00  Resp_cpu: 1594402830
  Access Path: index (index (FFS))
    Index: IX4_REQUEST
    resc_io: 3927.00  resc_cpu: 583211030
    ix_sel: 0.0000e+00  ix_sel_with_filters: 1
  Access Path: index (FFS)
    Cost:  3951.96  Resp: 3951.96  Degree: 1
      Cost_io: 3927.00  Cost_cpu: 583211030
      Resp_io: 3927.00  Resp_cpu: 583211030
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 1
******** Begin index join costing ********
  ****** trying bitmap/domain indexes ******
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 0
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 0
  ****** finished trying bitmap/domain indexes ******
******** End index join costing ********
  Best:: AccessPath: IndexFFS  Index: IX4_REQUEST
         Cost: 3951.96  Degree: 1  Resp: 3951.96  Card: 3994236.00  Bytes: 0
***************************************

I mentioned that it is a bug related to the ANSI SQL standard and transformation probably.

As suggested/asked in my first reply:
1. If you use a no_query_transformation then you should find that you get the use of the index (although not in the plan you would expect)
2. If you use the traditional Oracle syntax, then you should not have the same problem.

Recovery of the records by using the Ref Cursor or indexes per Table (which is better)
Hi all

I am interested to know if there is a performance (or other) advantages to return a result set from an Oracle stored procedure for a client application (for example, in Java) by using a Ref Cursor or Index by Table, respectively. Most of the people I met who know Java seem to use a Ref Cursor but did not say why this method is preferable. I'm not too familiar with Java and do not have the opportunity to test the difference between either method, but I am very interested in the other user forum about this view, gauging

Kind regards

Kevin.
KevinFitz wrote:
Hi zerathul,

Thanks for the quick and helpful response. A REF CURSOR would be the best solution if the same set of results (content and number of records returned) should be dealt with by the application of the 'customer '. I'm guessing that maybe in this situation 'theoretical' that there might be less network traffic to return the set of results through an associative array,

Kind regards

Kevin.

Yes, it would always be the best solution, because an associative array would mean collecting all the data in memory of expensive PGA on the database server before they pass any return on the network, while a fair Ref cursor is to feed the data over the network (maybe a little extra load, but you were unlikely to notice). Also the client application would treat a ref as of rows returned cursor data recovery and could treat them upon their arrival, an associative array is a collection of data which will then be entirely spent before any treatment could be done and then the treatment should go through the entire table to do.

REF CURSOR will also provide other information such as the error codes etc regarding SQL if necessary. If you get an error when filling a table on the side of the database, it is not so easy to recover this error to the client.

REF CURSOR is designed for this purpose. Use them.

How to index a table on multiple sites?

Hello

How to index a table on multiple sites?

I searched this issue and was not able to find the answer. I understand that it can be done with loops, but I don't know how.

I use the detector of crete vi for frequency domain data collected a VNA (s2p) file. The products contain a table of amplitudes and a table of locations. The problem is that the locations refer to the index of table of amplitude, which is not the same as the frequency. My idea is that I can use this output of the places table to index the frequency to the detected peak frequencies table and then draw these, as well as some analysis data and manipulation on them. Currently, I can do this only by consulting table on the front panel.

The entrance to the peak detector is currently a table 1 d of the scale (what is the problem?).

I also looked at the supply frequency & estimate VI, but this VI seems only exit of scalar data for the largest peak, not exactly what I'm looking for.

Thanks for your help.

You have a second table for the tested frequency? If so, then you are right that you just need to index this table with the indexes by the Ridge detector. Use a loop for. Automatic index to the index, use index in array to get the value of the frequency and autoindex on frequencies.

What is the physical meaning of automatic indexing of table entry...

What is the physical interpretation of the automatic indexing. ?

You wire up a table on the edge of a loop, it sequentially will index the table for you as he travels the loops. A While loop will also do this, but it is much more common on loops For, therefore, loops For making automatically while the While loops must be 'right click' and said to the index in the array. Get it?

sort of an index by table

Hi all

I have a button on a form to run reports,

There is a tabular block that has names of patients and a check box,

When a user check more than one box, baptisms of report,

When you close the first report, the second runs and so on.

the problem is that there is another element that maintains a number when you check in a patient,

If you check a patient, then the element holder is (1).

you check the second element holds (2),

but you can check the second record so that the point spacers (1), then check the first records in the block, so the first record holds (2),

When you click the button to run the reports,

(2) will be held the first (1), and that's what I don't want to happen, I want to sort them.

check who is the owner of one (1) works first, and who owns the tracks (2) second and so on.

I wrote this code in the button which runs reports, but is not what I want, it runs reports according to records not the numbers.

declare
V_PARM  PARAMLIST ;
     LST_REC NUMBER ;
    REQUEST_NUM NUMBER:=1;
   TYPE V_RECORD IS RECORD (V_VISIT_ID MR_PATIENT_VISITS.VISIT_ID%TYPE                         
   ,V_ORG_NO RC_PATIENT_EPISODES .ORGANIZATION_NO%TYPE
   ,V_NUM NUMBER);
  
   TYPE PRD_TYPE  IS TABLE OF  V_RECORD INDEX BY BINARY_INTEGER;
   PRD_TABLE PRD_TYPE;
BEGIN
    GO_ITEM('ALL_ADMITTED_PATIENT.PATIENT_FILE_NO') ;
    FIRST_RECORD ;
    LOOP
        IF :ALL_ADMITTED_PATIENT.CHECK_PAT = 'Y'
            THEN
           
            PRD_TABLE(:ALL_ADMITTED_PATIENT.NUM).V_VISIT_ID  := :ALL_ADMITTED_PATIENT.VISIT_ID;

             PRD_TABLE(:ALL_ADMITTED_PATIENT.NUM).V_ORG_NO := :ALL_ADMITTED_PATIENT.ORGANIZATION_NO;

             PRD_TABLE(:ALL_ADMITTED_PATIENT.NUM).V_NUM  := :ALL_ADMITTED_PATIENT.NUM;
            
            
  V_PARM := GET_PARAMETER_LIST('REPDATA');
  IF NOT ID_NULL(V_PARM) THEN
      DESTROY_PARAMETER_LIST(V_PARM);
  END IF;
  V_PARM := CREATE_PARAMETER_LIST('REPDATA'); 
  Add_Parameter(v_parm,'P_VISIT_ID'          ,TEXT_PARAMETER,    PRD_TABLE(:ALL_ADMITTED_PATIENT.NUM).V_VISIT_ID);
  Add_Parameter(v_parm,'P_ORGANIZATION_NO'   ,TEXT_PARAMETER,PRD_TABLE(:ALL_ADMITTED_PATIENT.NUM).V_ORG_NO);
  
  REQUEST_NUM := REQUEST_NUM +1;
  
  RUN_REPORT('MRSHTVIW',TO_NUMBER('1'),V_PARM ,'OCX_BLOCK.OCX'); 
  EXIT WHEN :SYSTEM.LAST_RECORD = 'TRUE' ;
  NEXT_RECORD ;
  ELSE
      EXIT WHEN :SYSTEM.LAST_RECORD = 'TRUE' ;
      NEXT_RECORD ;
      END IF ;
        END LOOP ;
    

END;



  
   -------------------

I want to sort the 'index by table' once he gets the data in it?

or any other solution

Many thanks to you all,.

Thank God I solved it, it comes to the latest version of my code that solved the problem:


 DECLARE
     V_PARM PARAMLIST ; 

     TYPE ADT_REC_TYPE IS RECORD (V_VISIT_ID VARCHAR2(90) ,
     V_ORG_NO VARCHAR2(90)
     ) ;
     ADT_REC ADT_REC_TYPE ;
     TYPE ADT_TAB_TYPE IS TABLE OF ADT_REC_TYPE
     INDEX BY BINARY_INTEGER  ;
     ADT_TAB ADT_TAB_TYPE ;
 BEGIN
      GO_BLOCK('ALL_ADMITTED_PATIENT') ;
      FIRST_RECORD;
      LOOP
      IF :ALL_ADMITTED_PATIENT.CHECK_PAT = 'Y'
            THEN
        ADT_TAB(:ALL_ADMITTED_PATIENT.NUM).V_VISIT_ID := :ALL_ADMITTED_PATIENT.VISIT_ID     ;
        ADT_TAB(:ALL_ADMITTED_PATIENT.NUM).V_ORG_NO   := :ALL_ADMITTED_PATIENT.ORGANIZATION_NO ; 

 END IF ; 

      EXIT WHEN :SYSTEM.LAST_RECORD = 'TRUE' ;
       NEXT_RECORD ;      

      END LOOP ; 

      FOR I IN ADT_TAB.FIRST .. ADT_TAB.LAST LOOP 

      V_PARM := GET_PARAMETER_LIST('REPDATA');
  IF NOT ID_NULL(V_PARM) THEN
      DESTROY_PARAMETER_LIST(V_PARM);
  END IF;
  V_PARM := CREATE_PARAMETER_LIST('REPDATA');  

  Add_Parameter(v_parm,'P_VISIT_ID'          ,TEXT_PARAMETER,    ADT_TAB(I).V_VISIT_ID);
  Add_Parameter(v_parm,'P_ORGANIZATION_NO'   ,TEXT_PARAMETER,ADT_TAB(I).V_ORG_NO);
  RUN_REPORT('MRSHTVIW',TO_NUMBER(:GLOBAL.LANGUAGE_ID),V_PARM ,'OCX_BLOCK.OCX');
END LOOP ;
     END ;

2015 CC Dreamweaver shows why not the border of the table. In the prevoios version Dreamweaver CS6 see the border of the table.

2015 CC Dreamweaver shows why not the border of the table. In the previous version of Dreamweaver CC see the border of the table.
See the difference
Dreamweaver CC 2015
Dreamweaver CS6

The first image shows 'Live' display, as the second watch design mode. That's what I think "Design" shows in the latest version of DW.

Why can't I create a table or a column whose name begins with a number?

Why can't I create a table or a column whose name begins with a number? I can't seem to find an answer when I Googled it.
Thank you
Yoann

Hello

jimmy437 wrote:

Why can't I create a table or a column whose name begins with a number? I can't seem to find an answer when I Googled it.

Thank you

Yoann

You can; Simply enclose it quotation marks name whenever you use it.

For example:

CREATE TABLE '3-26.
(
'name 1' VARCHAR2 (10)
);

INSERT INTO '3-26' ('1 St Name') VALUES ('FUBAR');

SELECT '1 name '.
"3-26;

Remember, what inside quotes is case-sensitive, so you can't refer to that column as "1st NAME.

Using quotation marks (and capitalizing exactly as expected) is such a pain that most people don't bother.

Why slow Adobe LR development?

Why slow Adobe LR development? It is a technical question, Adobe is not design a game that is infinitely more complex, but in the 2 years of game development, you would have most of the major components in place. They are not doing anything that is ground breaking, it is just another iteration of the same product, to prove my point, we in 2015 and they begin to use the GPU for processing power, which is almost half a decade (or more) behind where it should be and they have a bigger budget than most game studios.
An interesting point, LR5 (like this software immensely) came out after the opening, but he looks almost identical, had this impact on the plans of future development for Adobe? done at the last minute the change on its life cycle product?
They should focus on the sector of the games to inspire rather since they constantly develop and game engines all code from scratch in 2 years, the techniques used to exploit the different components of a computer that could benefit from this editing software and open channels new innovative features.

If you have not read the Forum guidelines and especially the section on label please do.

We are all here to help or to help, and we all have different ways, cultures and even languages...

Enjoy the rest of the weekend...

monitor the DML operation for a table, that is, monitor the type time and DML operation
Hello expert,

I want to follow the DML operation for a table, i.e. monitor the time to type and the DML operation. you tell please how do I get that?

Thank you very much
See if this can help you:

http://Oracle-Apps-DBA.blogspot.com/2007/07/monitoring-DML-operations.html

Kind regards

Why slow DML in Index organized tables

Similar Questions

Maybe you are looking for