Billing index-VKDFS table

Hi,
we have put a break point in include V05IEXIT for modyfying the above table VKDFS. but while creating invoices in background mode in VF04, the system is not coming to this include V05IEXIT in debugging mode.
we have to modify VKDFS-KUNNR
what to do?
regards
sachin

thanks for the reply. we will do as you have said. but i would like you to look at the follwoing as to the reason we are working on VKDFS table and advice us.......
we have a rquirement that if we make invoices for two deliveries, the system should make only one invoice. but the system did not allowed to make one invoice since the ship to party is different in both the deliveries. so we did coding in structure XVBPAK in include RV60AFZD to make ship to party equal during runtime and we were able to combine invoices.
sold to party/payer is same in sales order for the delivereis....
now things work well in invoice creation through VF01 mode but deliveries are no combining in background invoice creation mode through VF06 or Vf04.... why ???
somebody told us to see table VKDFS for background processing .he entries in this table are updated before invoices are created and after invoices are created, this table does not store any entires for the deliveiry nos.
when we saw table VKDFS, the ship to party is different, so we thought of making ship to party equal too here using exit V05IEXIT.. we have made ship to party/its address equal here tooo but still our delivereis are not combining in background invoice creation mode.
what is the reason that invoices combine in foreground mode and not in background mode.we know dueing background processing system uses program SDBILLDL.
regards
sachin

Similar Messages

Sd billing index table

Hi,
q1 ) what are index tables.
q 2 )specifically I want to know abut the functionality of sd index table VKDFS. What this table does?
regds

All SAP database table have one or more indexes. The key index is based on the table key fields, and other indexes are provided as required. The index is used by the system to access data in the table with the quickest time. If you try to read a table without supplying any of the index fields, the database will read the table one row at a time until a matching row is found. If the table has a lot of records it can take a very long time to access the required data. SAP programmer always trys to read table using the key or index fields for the best performance.
In some cases SAP provides additional tables for specific purpose called index tables. In this case VKDFS is used as billing initiator. When you want to view the billing due list (transaction VF04, then the system uses this table to list the dcouments due for billing. Although it is possible to analyse the documents due for billing by reading the status of the sales documents, this would take a long time to analyse all sales orders especially as many will either not be due for billing or already billed. This table is filled as you process the sales documents, so that th e system always has an up to date list of the items due for billing in this table. As the table has fields specified such as billing date, sold-to, sales org in the key, the peformance of the billing due list (VF04) is very fast when using any of those key fields.
Rgds
Richard

Delivery document available in VKDFS table. How to remove that?

Hi,
The scenario goes like this. I create purchase order,goods receipt and invoice. followed by which i create a return delivery for one line item . Now this return delivery gets added in VKDFS table. The reason is because billingtype is IV(Intercompany billing).
Item category of delivery is RLLN(Relevant for proforma). generally item category relevant for proforma doesnt get added in VKDFS. But since this is intercompany billing it is added in VKDFS.
Now my doubt is how or where do we give the billing type for delivery document.I mean where do we assign Intercompany billing to delivery document.....

Hello,
please run transaction 0VLK to dsiplay the involved delivery type.
Notice the field 'Default ord.ty' TVLK-DAART.
Run transaction VOV8 to display the order type in TVLK-DAART.
Here you can see the 'Intercomp.bill.type'
Best regards,
Ivano.

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

Rebate relevance and Billing index recompilation

Hello
I am in the process of building the configuration for the system, particularly rebates.
Initially the sales org was marked for rebate relevance, later unchecked and now checked once again.
No rebate agreements have been created in system.
3 billing documents have been created (belonging to billing type not relevant for rebates) which have not passed to accounting.
Do I need to run the billing index program under the above circumstance ?
Thanks and Best Regards
cds

Hello,
the rebate index table VBOX is updated when a billing documents is released to accounting, and it has:
- Sales org. relevant for rebate
- Payer relevant for rebate
- Billing type relevant for rebate
NO MATTER if rebate agreement exist or not.
In this case, if there are not billing documents with thoese characteristic released to accounting, then is not necessary to rebuild VBOX.
Best regards,
Ivano.

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.

Creation of context index on index-organized tables

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.

creation of domain indexes (such as context) on iot's
is not currently supported in oracle.

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

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)?

Creation of secondary indexes for table "RSBATCHCTRL_PAR" failed

Hi ,
We have installed EHP1 on our BI7.0 system successfully, later we are trying to apply SPS01 for this EHP but we got the follwoing error during TBATG conversion.
2 EGT092 Conversion of table "RSBATCHCTRL_PAR" was restarted
2 EGT241 The conversion is continued at step "6"
2 EGT246 Type of conversion: "T" -> "T"
2 EGT240XBegin step "RSBATCHCTRL_PAR-STEP6":
4 EGT281 sql:
4 ED0314 CREATE
4 ED0314 INDEX [RSBATCHCTRL_PAR~DB] ON [RSBATCHCTRL_PAR]
4 ED0314 ( [JOBNAME] ,
4 ED0314 [JOBCOUNT] ,
4 ED0314 [SERVER] ,
4 ED0314 [HOST] ,
4 ED0314 [WP_NO] ,
4 ED0314 [WP_PID] ,
4 ED0314 [PROCESS_TYPE] )
4 ED0314 WITH ( ONLINE=OFF )
4 ED0314 ON [PRIMARY]
2 ED0314 Line 1: Incorrect syntax near '('.
3 EDA093 "DDL time(___1):" ".........6" milliseconds
2EEGT236 The SQL statement was not executed
2EEDI006 Index " " could not be created completely in the database
2EEGT221 Creation of secondary indexes for table "RSBATCHCTRL_PAR" failed
2EEGT239 Error in step "RSBATCHCTRL_PAR-STEP6"
2 EGT253XTotal time for table "RSBATCHCTRL_PAR": "000:00:00"
2EEGT094 Conversion could not be restarted
2 EGT067 Request for "RSBATCHCTRL_PAR" could not be executed
1 ED0327XProcess..................: "ferrari_12"
1 ED0302X=========================================================================
1 ED0314 DD: Execution of Database Operations
1 ED0302 =========================================================================
1 ED0327 Process..................: "ferrari_12"
1 ED0319 Return code..............: "0"
1 ED0314 Phase 001................: < 1 sec. (Preprocessing of TBATG)
1 ED0314 Phase 002................: < 1 sec. (Partitioning)
1 ED0309 Program runtime..........: "< 1 sec."
1 ED0305 Date, time...............: "03.06.2009", "12:47:21"
1 ED0318 Program end==============================================================
1 ETP166 CONVERSION OF DD OBJECTS (TBATG)
1 ETP110 end date and time : "20090603124721"
1 ETP111 exit code : "8"
1 ETP199 ######################################
System properties:
SAP - BI7.0 with EHP1
Database - MSSQL 2000
OS - Windows2003
Please suggest.
Thanks in advance,
Pavan.

> We have installed EHP1 on our BI7.0 system successfully, later we are trying to apply SPS01 for this EHP but we got the follwoing error during TBATG conversion.
> 2 ED0314 Line 1: Incorrect syntax near '('.
> 3 EDA093 "DDL time(___1):" ".........6" milliseconds
> 2EEGT236 The SQL statement was not executed
This is a known problem with SQL Server 2000, see
Note 1180553 - Syntax error 170 during index creation on SQL 2000
I highly suggest upgrading to SQL Server 2005 or 2008.
Markus

Creation of indexes in tables

SAP 4.7 6.20 Oracle 10g Windows Server 2003
Our SAP system was based on SQL.
Last month it was changed to Oracle 10g.
We really have a lot of developments ( Z programs ), and it's normal for us to create indexes some times.
But I don't know if we are supposed to change our habits from now on because of Oracle.
I have 2 questions :
1) Is the creation of indexes in tables so effective in Oracle as it was for SQL databases ?
2) When I create an index, Am I supposed to use the field MANDT as part of the index ?
Eduardo

Hi,
We are on Oracle 10.2.4.0 .My answers for point
1. Ensure that oracle patches are up-to-date. Also oracle parameters are set correctly.There is one S-note(do not remember right now) which has script file which you can run on your system to find if oracle parameters are set according to recommendation.
2. Mandt can be used in Z programs.Not a problem.
For future: Analyze Expensive SQl statements with the help of St03N and St04 for next2-3 months and tune them.
Does it help

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.

Need suggestion on adding Index on table

Hi,
There is table called customer_locations in my database which has records about more then 5000 rows, When we write some select query to fetch data from this table takes too much time to load the data.
Need a suggestion how to add index to increase the performance on this table. also which type of index to be added need a suggestion
table sql script is mentioned below
CREATE TABLE "CUSTOMER_LOCATIONS"
(     "LOCATION_ID" NUMBER NOT NULL ENABLE,
     "COMPANY_NAME" VARCHAR2(512),
     "ADDRESS_LINE_1" VARCHAR2(512),
     "ADDRESS_LINE_2" VARCHAR2(512),
     "PHONE_NUMBER" VARCHAR2(255),
     "FAX_NUMBER" VARCHAR2(255),
     "CITY" VARCHAR2(512),
     "STATE" VARCHAR2(512),
     "ZIP" VARCHAR2(100),
     "COUNTRY" VARCHAR2(255),
     "CREATED_BY" VARCHAR2(512),
     "CREATED_DATE" TIMESTAMP (6),
     "MODIFIED_BY" VARCHAR2(512),
     "MODIFIED_DATE" TIMESTAMP (6),
     "DOMAIN_ID" NUMBER,
     "LOCATION_TYPE" VARCHAR2(255),
     "STATUS" VARCHAR2(50),
     "IB_STATUS" VARCHAR2(100),
     "OLD_LOCATION_ID" VARCHAR2(50),
     CONSTRAINT "SS_CUSTOMER_LOCATIONS_PK" PRIMARY KEY ("LOCATION_ID") ENABLE
Please suggest
Thanks
Sudhir

Hi Sudhir,
Since you have no predicates it would be unavoidable to have FULL TABLE SCAN. But let me tell you that FULL TABLE SCANS are not bad.
Just to help you with, the below code can enunciate the use of Indexes:
drop table test_table;
create table test_Table as select * from all_objects where rownum < 5001;
select * from user_ind_columns where table_name = 'TEST_TABLE';
--No rows fetched.
explain plan for
select object_name || ' is a ' || object_type as OBJ_DESC, object_id
from test_table;
--5000 Rows fetched
select operation, options, object_name, object_alias, object_instance, object_type, optimizer, depth, position, cost, cardinality, cpu_cost, io_cost
from plan_table;
OPERATION               OPTIONS     OBJECT_NAME     OBJECT_ALIAS          OBJECT_INSTANCE     OBJECT_TYPE     OPTIMIZER     DEPTH     POSITION     COST     CARDINALITY     CPU_COST     IO_COST
SELECT STATEMENT     (NULL)     (NULL)          (NULL)                    (NULL)               (NULL)          ALL_ROWS     0          19               19          5000          1698651          19
TABLE ACCESS          FULL     TEST_TABLE     TEST_TABLE@SEL$1     1                    TABLE          (NULL)          1          1               19          5000          1698651          19
alter table test_Table add constraint pk_object_id PRIMARY KEY (object_id);
explain plan for
select object_name || ' is a ' || object_type as OBJ_DESC, object_id
from test_table
where object_id = 26;
select operation, options, object_name, object_alias, object_instance, object_type, optimizer, depth, position, cost, cardinality, cpu_cost, io_cost
from plan_table
where statement_id = 'WITH_PK';
OPERATION               OPTIONS               OBJECT_NAME          OBJECT_ALIAS          OBJECT_INSTANCE     OBJECT_TYPE          OPTIMIZER     DEPTH     POSITION     COST     CARDINALITY     CPU_COST     IO_COST
SELECT STATEMENT     (NULL)               (NULL)               (NULL)                    (NULL)               (NULL)               ALL_ROWS     0          2               2          1               15543          2
TABLE ACCESS          BY INDEX ROWID     TEST_TABLE          TEST_TABLE@SEL$1     1                    TABLE                              1          1               2          1               15543          2
INDEX                    UNIQUE SCAN          PK_OBJECT_ID     TEST_TABLE@SEL$1     (NULL)               INDEX (UNIQUE)     ANALYZED     2          1               1          1               8171          1Let me know if it help or if you still have any concerns.
Regards,
P
Edited by: PurveshK on May 29, 2012 12:40 PM

Question about Global index and Table Partitions

I have created a global index for a partitioned table now in the future the partitions will be dropped in the table. Do I need to do anything to the global index? Does it need to be rebuilt or would it be ok if partitions get dropped in the table?

>
I have created a global index for a partitioned table now in the future the partitions will be dropped in the table. Do I need to do anything to the global index? Does it need to be rebuilt or would it be ok if partitions get dropped in the table?
>
You can use the UPDATE INDEXES clause. That allows users to keep using the table and Oracle will keep the global indexes updated.
Otherwise, as already stated all global indexes will be marked UNUSABLE.
See 'Dropping Partitions' in the VLDB and Partitioning Guide
http://docs.oracle.com/cd/E11882_01/server.112/e25523/part_admin002.htm#i1007479
>
If local indexes are defined for the table, then this statement also drops the matching partition or subpartitions from the local index. All global indexes, or all partitions of partitioned global indexes, are marked UNUSABLE unless either of the following is true:
You specify UPDATE INDEXES (Cannot be specified for index-organized tables. Use UPDATE GLOBAL INDEXES instead.)
The partition being dropped or its subpartitions are empty

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.

Billing index-VKDFS table

Similar Messages

Maybe you are looking for