How to handle alternate index in DB2?

guruji · New User Joined: 13 Apr 2007 Posts: 59 Location: Chennai

Hi,

I am doing a conversion from an existing VSAM file into a DB2 table. While maping the variables, I found a difficulty in handling the alternate Index that is exixting in VSAM.

Could you please suggest me a solution?

Thanks,
Reni

dick scherrer · Posted: Mon Jun 18, 2007 6:26 am

Hello,

For us to be able to help with this question

guruji · New User Joined: 13 Apr 2007 Posts: 59 Location: Chennai

The problem I faced is nothing else but how to map the VSAM alternate indexes to DB2?
Is it something like handling creting more than one index corresponding to the AIX in VSAM?

Thanks,
Reni

Phrzby Phil · Posted: Tue Jun 19, 2007 5:46 pm

If you are traversing the VSAM file via the alternate index in COBOL, and you want the new DB2 program to see the records in the same order (which presumably you do), then you will most likely replace your VSAM processing with a DB2 cursor whose SELECT's ORDER BY clause specifies the record order matching your VSAM alt index.

If you do this frequently, or have lots of records when you do, then having a key built on these fields will assist efficiency.

Real DB2 experts (which I am not) - please chime in here.

dick scherrer · Posted: Tue Jun 19, 2007 6:25 pm

Hello,

In addition to defining a cursor that retrieves the rows in the needed order, the fields in question need to be defined as indexes to db2 to provide direct access rather than a full table traversal.

Phrzby Phil · Posted: Tue Jun 19, 2007 6:57 pm

Dick -

Doesn't the issue of having an index on those fields relate to table size?

Also, if the table is very frequently updated, therefore requiring lots of index maintenance overhead, but the cursor in question seldom needed, then might it be better to forget the index and allow an occasional full traversal?

dick scherrer · Posted: Tue Jun 19, 2007 7:20 pm

Hello,

That would be the ever famous "it depends".

If it is a multiple-hundred million row table any full traversal will have a noticable impact. If it is a 100 or 1000 row table, a full traversal will barely be noticed.

The same with additional index definitions. Records are inserted and deleted only once, so there is that one-time cost of the additional index(es). If these index fields are changed quite often, that would need to be considered. If rows are added and not purged for a very long time, additional index entries speed lots of different queries and batch processing. If rows are used very often in online and ad-hoc queries/reporting, additional indexes are usually your friend.

The index entries are not stored with the table data, so the actual table data size does not increase - index space would increase, but that is usually not linear.

If there is doubt about which way to go, it is a good idea to test different approaches. The alternative to use may become obvious or it may not. One of the things i've found tougher to test is getting a couple hundred or a couple thousand concurrent "users" to see how the alternatives perform when not running in an isolated environment (i.e. single tester/process). Sometimes an isolated test is quite sufficient to demonstrate an unattractive alternative

.

As i mentioned at the beginning of this reply - it depends, but i encourage in depth testing for anything that may be a critical process or substantial resource consumer.

ameen.syed · New User Joined: 23 Jun 2007 Posts: 2 Location: bangalore

Will creating of Referencial - keys in DB2, help in mapping of Alternate index in VSAM???PLz let me know

dick scherrer · Posted: Fri Aug 03, 2007 6:17 pm

Hello,

There is no relationship bewteen DB2 keys and alternate indexes in vsam. They are in completely different environments.

If you clarify your question, we may be able to offer suggestions.

stodolas · Posted: Fri Aug 03, 2007 6:24 pm

Also note, even with an alternate index, you can't ensure the rows are in any kind of order without using the ORDER BY.

dbzTHEdinosauer · Posted: Fri Aug 03, 2007 7:12 pm

it appears that your table design was based on the vsam record format. rarely does a vsam record convert directly to a db2 row if any normalization has been done. The quick and dirty get it done now will always bite your butt later! (I know that one should not use always when talking about computers, but I was actually talking about lazyness)