Is Index organization tables better in performance compare to normal tables

Question

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

Answer 1

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