|
Someone else said it better but there is more to indexes than the index type or the command that creates them. A few examples may help to make this point. An index can be 3-byte or 4-byte. The 3-byte kind is called the "4-gigabyte" type and the 4-byte kind is called a "1-terabyte" type. The 4GB indexes are smaller and can be slightly faster than 1TB indexes. However, if there are a lot of key updates, the 1TB index is a far better choice because it manages contention much better. Unlike Oracle, the AS/400 doesn't use static data about the contents of tables to optimize a query. The AS/400 dynamically builds an "access plan" using the actual contents of the database table at the instant that the plan is being constructed. The access plan saves the results from optimizing the query. In most cases, the access plan is saved so that a subsequent query can reuse the plan without rebuilding it. If a table changes in certain ways, the access plan will be rebuilt. Unfortunately, since there is no static meta-data stored about the physical data in the table, the optimizer has to probe the table to determine how many values of this or that are present and make optimizing decisions based on what it can find in a short period of time. However, you can create an Encoded Vector Index. This is a kind of dynamically maintained collection of static table information. Last week or early this week, someone posted a note that, if a certain PTF is applied, the SQL CREATE INDEX command will create indexes with a larger page size than you can build with CRTLF. I don't understand everything that I know about this but the idea is that you can find your data with fewer page faults if the index pages are larger. That means better performance. I do a lot of database performance tuning with the JDE OneWorld package. JDE does a lot of index updates so it is much better to use the 1TB index type. It is also important to review the SMAPP setting. Since JDE is doing lots of index updates, there are a very large number of physical disk write operations to the system journals for JDE tables. This is especially true if batch jobs create a large number of database update operations. This may not be important by itself but users may submit jobs using an order by clause that they specify - the application doesn't prescribe the sequence. If an index with the right keys for a particular order by doesn't exist, the application may perform very poorly. The solution is create a new index with the right keys. Except, this new index adds to the list of indexes being changed during those batch jobs. This causes more SMAPP writes, and so forth. There is more to database indexes and their contribution to performance than the index type. I wrote this note because I don't understand your question. If we are to answer your question fully, we need a little better idea of what you are thinking or observing. If you are having a problem, explain it and tell us about what you are seeing - we will try to help. If you don't know where to start, explain the design and the situation and we will try to help you understand the issues better. Why is this question important to you? I am pretty sure that the others on the list don't understand your question either. Please let us help! Richard Jackson mailto:richardjackson@richardjackson.net www.richardjacksonltd.com Voice: 1 (303) 808-8058 Fax: 1 (303) 663-4325 -----Original Message----- From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On Behalf Of AKumar@rccl.com Sent: Friday, July 14, 2000 12:08 PM To: MIDRANGE-L@midrange.com Subject: DB2 - Index Hi, I am trying to use different indexes in stored procedure to maximize the performance . There are three choices of creating index. CASE I) Create logical file. CASE 2) CREATE INDEX .......... CASE 3) CREATE ENCODED VECTOR INDEX.......... Q 1) What kind of index is created when we create Logical File? Q 2) If there is some thumb rule (or rule) which I need to follow during going for a index? It is very important for us. Regards, Ajay Kumar 305-539-6621. +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.