What is index oragnized table

hi can you tell me
1.what is index oragnized table
2. fragmentation of table
3. what is cascading trigger mean

Hi,
For this points a good starting point are Oracle Manuals. For index organizated tables check this link [Overview of Index-Organized Tables|http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#sthref1044].
Cascading triggers should be avoided, see this link [Some Cautionary Notes about Triggers|http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/triggers.htm#sthref3187]
Regards,
Edited by: Walter Fernández on Jan 28, 2009 4:21 PM - Adding information about cascading triggers

Similar Messages

Index Vs table partition

I have table whose growth is 1 million per month and may increase in future. I currently place an index on column which is frequently uses in where clause. there is another column which contains months so it may possible that I make 12 partitions of that. I want to know what is suitable. is there any connection between index and table partition?
Message was edited by:
user459835

I think the question is more of what type of queries are answered by this table?
is it that most of the times the results returned span across several months?
is there any relation to the column you use in where clause with the data belonging to a particular month (or range there-of)?

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.

Finding Parent Table of Index Organized Table

I am using Oracle 10g Rel 2 and faced error message while granting select priviliges ORA-25191: cannot reference overflow table of an index-organized table
I searched solution and found: Issue the statement against the parent index-organized table containing the specified overflow table.
Question is how can i find parent index-organized table containing the specified overflow table.
Further i faced an other error while granting select priviliges : ORA-22812: cannot reference nested table column's storage table
Solution is same and i found parent table and first granted select priviliges on that parent table and then tried then tried to grant select priviliges on required table to public and did not worked.
if some body could help me!!!!!!!!!!!!!!!!!!!!!

And just what does this problem have to do with either the SQL and/or PL/SQL languages?
Try the [url http://forums.oracle.com/forums/forum.jspa?forumID=61&start=0]Community Discussion Forums » Database » Database - General forum.
Also suggest that you read up on just what an IOT is, and where and when overflows apply. See the [url http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#sthref1060]Oracle® Database Concepts guide.

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

Heap tables and index organized tables

I performing migration from mssql server to oracle 10gr2 rdbms, in mssql all tables have clustered pk, index. Is it necessary to use index organized tables for that migration, or enough ordinal heap organized tables and what differences between those tables, and mssql tables
Thanx

In Oracle, the typical table is a standard 'heap' table. Stuff goes into the heap table randomly, and randomly comes out.
An Index Organizaed Tables is somewhat similar to a Cluster Index in SS. It can have some performance advantages over heap tables - when the heap table has an associated index on the primary key.
The IOT can also have some disadvantages, such as the need for an Overflow table to handle the extra data when a row doesn't conveniently fit in a block (implying multiple I/Os), and an extra translation table if bitmap indexes are required (implying extra I/Os).
An unintelligent developer will generally believe that Oracle and SQL Server are the same - after all they both run SQL - and will attempt to port by a simple translation of syntax.
An intelligent developer will test both styles of tables, during a port. Such a developer will also be quick to learn about the changes in internals (such as locking mechanisms) and will realize that different styles of coding are required for many application situations.
I recommend reading Tom Kyte's books to get handle on pros and cons as well as testing techniques to help a developer become intelligent.

Indexes on Index Organized Table

I remember seeing a note regarding problems in using indexs on index organized tables. Of course, the index would be something other than the one implied in the table definition. I can't seem to remember what the problem was.
Has anyone used indexes on index organized tables successfully? (unsuccessfully?)
Oracle 8i on a Tru64 platform
Thanks
-dave

I remember seeing a note regarding problems in using indexs on index organized tables. Of course, the index would be something other than the one implied in the table definition. I can't seem to remember what the problem was.
Has anyone used indexes on index organized tables successfully? (unsuccessfully?)
Oracle 8i on a Tru64 platform
Thanks
-dave

URGENT: INDEX BY TABLES IN FORMS 6i

Hi, i have created a package that manages an Index by Table locally to a form (i.e. not on the server). At one poin in the form, after posting changes, i use a procedure to fill in this table and leave it there for future reference.
My problem is that i can't reference exactly the same table with the data that was filled in after the post.
Here's what i do:
DECLARE
x UPDATE_DISPLAY_BLOCK.sync_tab;
BEGIN
UPDATE_DISPLAY_BLOCK.fill_sync_tab(x);
END;
I have declared 'x' locally to the trigger where this procedure is called. How can i see the same table 'x' for use in another trigger?
Many thanks,

It's not a matter of one session not seeing what was posted by another session. In fact i do 'post' the data and this causes no problem.
The problem resides in having to declare 'x' locally to the program unit which is inside a trigger:
DECLARE
x UPDATE_DISPLAY_BLOCK.sync_tab;
BEGIN
UPDATE_DISPLAY_BLOCK.fill_sync_tab(x);
END;
I want to reference the same 'x' somewhere else in the form without having to declare it again, like:
BEGIN
UPDATE_DISPLAY_BLOCK.delete_sync_tab(x);
END;
which obviously gives an error "object 'x' was not declared"
Regards

What are hte pooled tables

Hello,
I dont know what are the pooled tables in ABAP. Please any one help me to know this question.
I will be thankfull to all,
By
satish

Hi,
Here i am giving the definitions and differences between
different table types in SAP.
It gives you clear idea.
You can also go thru. below link
http://web.mit.edu/ist/org/admincomputing/dev/sap_table_types.htm
I. Transparent tables (BKPF, VBAK, VBAP, KNA1, COEP)
Allows secondary indexes (SE11->Display Table->Indexes)
Can be buffered (SE11->Display Table->technical settings) Heavily updated tables should not be buffered.
II. Pool Tables (match codes, look up tables)
Should be accessed via primary key or
Should be buffered (SE11->Display Table->technical settings)
No secondary indexes
Select * is Ok because all columns retrieved anyway
III. Cluster Tables (BSEG,BSEC)
Should be accessed via primary key - very fast retrieval otherwise very slow
No secondary indexes
Select * is Ok because all columns retrieved anyway. Performing an operation on multiple rows is more efficient than single row operations. Therefore you still want to select into an internal table. If many rows are being selected into the internal table, you might still like to retrieve specific columns to cut down on the memory required.
Statistical SQL functions (SUM, AVG, MIN, MAX, etc) not supported
Can not be buffered
IV. Buffered Tables (includes both Transparent & Pool Tables)
While buffering database tables in program memory (SELECT into internal table) is generally a good idea for performance, it is not always necessary. Some tables are already buffered in memory. These are mostly configuration tables. If a table is already buffered, then a select statement against it is very fast. To determine if a table is buffered, choose the 'technical settings' soft button from the data dictionary display of a table (SE12). Pool tables should all be buffered
Hope this clears your doubt.
Note: Please reward the points for helpful answers.
Regards,
Gopinath Addepalli

Primary key constraint for index-organized tables or sorted hash cluster

We had a few tables dropped without using cascade constraints. Now when we try to recreate the table we get an error message stating that "name already used by an existing constraint". We cannot delete the constraint because it gives us an error "ORA-25188: cannot drop/disable/defer the primary key constraint for index-organized tables or sorted hash cluster" Is there some sort of way around this? What can be done to correct this problem?

What version of Oracle are you on?
And have you searched for the constraint to see what it's currently attached to?
select * from all_constraints where constraint_name = :NAME;

How can I use Indexed Temp tables to optimize performance?

Instead of joining two CTEs together, I am now going to attempt to join two indexed temp tables.
The first temp table is a number of encounters that returns 147 rows in 2 seconds. The second temp table
is progress notes for all those encounters returning 136 rows in 18 seconds. Joining the indexed views comes back at 3 1/2 minutes.
What can I do to optimize performance?
Code is below. Thanks in advance!
if object_id('tempdb..#arpb') is not null begin drop table #arpb end;
if object_id('tempdb..#progress_notes') is not null begin drop table #progress_notes end;
SELECT DISTINCT
ARPB.PAT_ENC_CSN_ID, ARPB.SERVICE_DATE, ARPB.BILLING_PROV_ID, ARPB.DEPARTMENT_ID,
SER.PROV_NAME, DEP.DEPARTMENT_NAME, E.APPT_TIME, ZC_APPT.NAME AS APPT_STATUS
INTO #arpb
FROM ARPB_TRANSACTIONS ARPB
LEFT OUTER JOIN CLARITY_SER AS SER ON SER.PROV_ID = ARPB.BILLING_PROV_ID
LEFT OUTER JOIN CLARITY_DEP AS DEP ON DEP.DEPARTMENT_ID = ARPB.DEPARTMENT_ID
LEFT OUTER JOIN PAT_ENC AS E ON E.PAT_ENC_CSN_ID = ARPB.PAT_ENC_CSN_ID
LEFT OUTER JOIN ZC_APPT_STATUS AS ZC_APPT ON ZC_APPT.APPT_STATUS_C = E.APPT_STATUS_C
WHERE ARPB.DEPARTMENT_ID = xxxx
AND ARPB.TX_TYPE_C = 1
AND ARPB.VOID_DATE IS NULL
AND ARPB.BILLING_PROV_ID = xxxx
AND ARPB.SERVICE_DATE BETWEEN
'xxxx' AND 'xxxxx'
create clustered index idx_temp_arpb on #arpb(PAT_ENC_CSN_ID)
SELECT DISTINCT
ARPB.PAT_ENC_CSN_ID,
ZCNT.NAME AS NOTE_TYPE, PR.NAME AS PURPOSE, HNO_INFO.NOTE_ID,
EMP.NAME AS EMP_NAME, STS.NAME AS NOTE_STATUS
INTO #progress_notes
FROM ARPB_TRANSACTIONS ARPB
LEFT OUTER JOIN ENC_NOTE_INFO AS ENC_NOTE_INFO ON ARPB.PAT_ENC_CSN_ID = ENC_NOTE_INFO.PAT_ENC_CSN_ID
LEFT OUTER JOIN HNO_INFO AS HNO_INFO ON ENC_NOTE_INFO.ENCOUNTER_NOTE_ID = HNO_INFO.NOTE_ID
LEFT OUTER JOIN ZC_NOTE_TYPE AS ZCNT ON ZCNT.NOTE_TYPE_C = ENC_NOTE_INFO.NOTE_TYPE_C
LEFT OUTER JOIN ZC_NOTE_PURPOSE AS PR ON PR.NOTE_PURPOSE_C = HNO_INFO.NOTE_PURPOSE_C
LEFT OUTER JOIN CLARITY_EMP AS EMP ON EMP.EPIC_EMP_ID = HNO_INFO.CURRENT_AUTHOR_ID
LEFT OUTER JOIN ZC_NOTE_STATUS AS STS ON STS.NOTE_STATUS_C = ENC_NOTE_INFO.NOTE_STATUS_C
WHERE ARPB.DEPARTMENT_ID = xxxx
AND ARPB.TX_TYPE_C = 1
AND ARPB.VOID_DATE IS NULL
AND ARPB.BILLING_PROV_ID = xxxx
AND ZCNT.NAME = 'xxxx'
AND ARPB.SERVICE_DATE BETWEEN
'xxxx' AND 'xxxx'
AND PR.NAME = 'xxxxx'
create index idx_temp_pn on #progress_notes(PAT_ENC_CSN_ID)
SELECT
#arpb.PAT_ENC_CSN_ID,
#arpb.APPT_TIME,
#arpb.SERVICE_DATE,
#arpb.BILLING_PROV_ID,
#arpb.PROV_NAME,
#arpb.DEPARTMENT_ID,
#arpb.DEPARTMENT_NAME,
#progress_notes.EMP_NAME as NoteEmp,
CASE #progress_notes.NOTE_ID
WHEN null THEN 'No Progress Note'
ELSE #progress_notes.NOTE_ID
END as NoteId,
#progress_notes.NOTE_STATUS,
#progress_notes.NOTE_TYPE,
#progress_notes.PURPOSE
FROM #ARPB
LEFT JOIN #PROGRESS_NOTES ON #ARPB.PAT_ENC_CSN_ID = #PROGRESS_NOTES.PAT_ENC_CSN_ID
To err is human, to REALLY foul things up requires a computer

Something is not right here. What is the type of that column in both temp tables?
I would assume that joining 147 and 136 rows should be done in less than 1 sec. even without indexes.
How did you measure the time?
BTW, I suggest to use aliases in your last query - it will be easier to read. Also use COALESCE function instead of CASE for the Note_ID (BTW, is Note_ID a character column - otherwise you supposed to get an error).
For every expert, there is an equal and opposite expert. - Becker's Law
My blog
My TechNet articles

When will i use index organization table.

when will i use index organization table.
what is the advantage of these.

See the sit
http://www.dba-oracle.com/t_index_organized_tables.htm

WHAT IS INDEXING IN DATABASE ?

WHAT IS INDEXING IN DATABASE ? HOW CAN WE USE IT ?
BEST REGARDS,
RYAN

Hi
Indexes can be defined in the ABAP Dictionary to speed up access to data in a table. These indexes are also created in the database.
Performance during table access
Indexes
Primary and secondary indexes
Structure of an index
Accessing tables using indexes
Primary and secondary indexes
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Database access using Buffer concept
Buffering allows you to access data quicker by letting you
access it from the application server instead of the database.
Advantages of buffering
Table buffering increases the performance when the records of the table are read.
As records of a buffered table are read directly from the local buffer of the application server on which the accessing transaction is running, time required to access data is greatly reduced. The access improves by a factor of 10 to 100 depending on the structure of the table and on the exact system configuration.
If the storage requirements in the buffer increase due to further data, the data that has not been accessed for the longest time is displaced. This displacement takes place asynchronously at certain times which are defined dynamically based on the buffer accesses. Data is only displaced if the free space in the buffer is less than a predefined value or the quality of the access is not satisfactory at this time.
Entering $TAB in the command field resets the table buffers on the corresponding application server. Only use this command if there are inconsistencies in the buffer. In large systems, it can take several hours to fill the buffers. The performance is considerably reduced during this time.
Concept of buffering?
The R/3 System manages and synchronizes the buffers on the individual application servers. If an application program accesses data of a table, the database interfaces determines whether this data lies in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The buffer can therefore satisfy the next access to this data.
The buffering type determines which records of the table are loaded into the buffer of the application server when a record of the table is accessed. There are three different buffering types.
With full buffering, all the table records are loaded into the buffer when one record of the table is accessed.
With generic buffering, all the records whose left-justified part of the key is the same are loaded into the buffer when a table record is accessed.
With single-record buffering, only the record that was accessed is loaded into the buffer.
Buffering types
With full buffering, the table is either completely or not at all in the buffer. When a record of the table is accessed, all the records of the table are loaded into the buffer.
When you decide whether a table should be fully buffered, you must take the table size, the number of read accesses and the number of write accesses into consideration. The smaller the table is, the more frequently it is read and the less frequently it is written, the better it is to fully buffer the table.
Full buffering is also advisable for tables having frequent accesses to records that do not exist. Since all the records of the table reside in the buffer, it is already clear in the buffer whether or not a record exists.
The data records are stored in the buffer sorted by table key. When you access the data with SELECT, only fields up to the last specified key field can be used for the access. The left-justified part of the key should therefore be as large as possible for such accesses. For example, if the first key field is not defined, the entire table is scanned in the buffer. Under these circumstances, a direct access to the database could be more efficient if there is a suitable secondary index there.
With generic buffering, all the records whose generic key fields agree with this record are loaded into the buffer when one record of the table is accessed. The generic key is a left-justified part of the primary key of the table that must be defined when the buffering type is selected. The generic key should be selected so that the generic areas are not too small, which would result in too many generic areas. If there are only a few records for each generic area, full buffering is usually preferable for the table. If you choose too large a generic key, too much data will be invalidated if there are changes to table entries, which would have a negative effect on the performance.
A table should be generically buffered if only certain generic areas of the table are usually needed for processing.
Client-dependent, fully buffered tables are automatically generically buffered. The client field is the generic key. It is assumed that not all of the clients are being processed at the same time on one application server. Language-dependent tables are a further example of generic buffering. The generic key includes all the key fields up to and including the language field.
The generic areas are managed in the buffer as independent objects. The generic areas are managed analogously to fully buffered tables. You should therefore also read the information about full buffering.
Single-record buffering is recommended particularly for large tables in which only a few records are accessed repeatedly with SELECT SINGLE. All the accesses to the table that do not use SELECT SINGLE bypass the buffer and directly access the database.
If you access a record that was not yet buffered using SELECT SINGLE, there is a database access to load the record. If the table does not contain a record with the specified key, this record is recorded in the buffer as non-existent. This prevents a further database access if you make another access with the same key
You only need one database access to load a table with full buffering, but you need several database accesses with single-record buffering. Full buffering is therefore generally preferable for small tables that are frequently accessed.
Synchronizing local buffers
The table buffers reside locally on each application server in the system. However, this makes it necessary for the buffer administration to transfer all changes made to buffered objects to all the application servers of the system.
If a buffered table is modified, it is updated synchronously in the buffer of the application server from which the change was made. The buffers of the whole network, that is, the buffers of all the other application servers, are synchronized with an asynchronous procedure.
Entries are written in a central database table (DDLOG) after each table modification that could be buffered. Each application server reads these entries at fixed time intervals.
If entries are found that show a change to the data buffered by this server, this data is invalidated. If this data is accessed again, it is read directly from the database. In such an access, the table can then be loaded to the buffer again.
REWARD IF USEFULL

What are indexs?

Hi Experts,
Could any body tell me what are indexes .
What EXACTLY happens when we create the a indexs on a cube.?
Regards,
RG

Hi Friend,
Indices are used to locate needed records in a data-base table quickly.BW uses two types of indices, B-tree indices for regular database tables and bitmap indices for fact tables and aggregates tables.
These Bitmap indices cannot able to handle any inserts, updates, deletion. Bcoz of that we have to delete the indices before loading and have to rebuild it after loading.
But if u use the B-Tree indices there is no need for deletion of indices as B-tree can able to handle it very well.
B-tree indices: B-tree indices are used when dealing with huge volume of data. Line Item dimensions use B-tree indices.
Bitmap indices: for fact tables and aggregate tables: This is for regular database tables. Bitmap Indices can dramatically improve query performance when table columns contain few distinct values. Except LID other dimensions use bitmap indices
Thanks

Creation of context index on index-organized table

I encountered a problem when creating a domain index(intermediate text context index) on a index-organised table in oracle 8i.
The description of the error is stated below:
"ORA-29866: cannot create domain index on a column of index-organized table "
I have configured intermediate text properly and even it worked for those tables which are not index-organised(ordinary tables).
This problem has occured only when i made the tables as index organised.
Please provide us a solution to this problem as early as possible.
In case if you require any more details i shall provide them.

Please ask questions about Oracle Text (formerly interMedia text) in the Oracle Text forum. You will get a quicker, more expert answer there.

What is index oragnized table

Similar Messages

Maybe you are looking for