David Daugherty posed this question: In a particular EVI, is it better to have few fields in a particular index and have many EVIs? Or is it better to stack as many fields in one index as you can to reap the benefits of EVIs?
EVIs are designed to improve the performance of record selection. The traditional indexes on the iSeries are binary radix tree indexes, and while I don't really care how the indexes function, I do need to know when to use each type. Traditional indexes are well-suited to sorting records into the correct order or selecting a relatively specific group of records from a large file. EVIs are best used for selecting all the records that match a certain value when there are many records that match that same value.
For example, I made a copy of the QADBIFLD file called KPFFLD, which contains a list of every field in every file in DB2. The Data Type column contained 16 distinct values, which I determined by running this SQL statement:
Because there are so many records with exactly the same value in the data type column, it's not a good candidate for the traditional index. If I want to improve the performance of a Select against this column, an EVI is much better. To test this, I ran a simple Select that retrieves every column name from every file that has a data type of 'CHAR'.
Using Visual Explain from within iSeries Navigator, I can see that the SQL engine is recommending that I create an EVI index over the DBITYP column. Visual Explain contains wizards to help with this, or I can create the index the old fashion way with this SQL statement:
20 DISTINCT VALUES
The "20 DISTINCT VALUES" clause simply provides a "ballpark" estimate to the SQL engine as to how many distinct values it should expect to find in that column. Take a guess; if you're wrong, it's not a problem. If the SQL engine finds more than you predicted, it simply allocates more space. So try to make a reasonable guess with a little room for growth.
Remember that EVI indexes are not meant for every situation. Don't create them unless you are confident you understand when to use them. The rule to remember for EVIs is that they work well for selecting data from columns where there are few distinct values. Columns such as payroll type might contain, for example, an "S" for salary or an "H" for hourly. State name columns might contain 50 distinct values for a database with a million records. Those are both classic examples of columns that you might want to build an EVI over.
To specifically answer David's question, it's a good rule of thumb to avoid building EVIs with multiple fields. The SQL engine will combine multiple indexes to achieve its goal, which means you need to build fewer indexes in the long run. There are exceptions to every rule though, and you may find certain situations where some columns are always used in combinations that might benefit from a more complex EVI.
You may not use EVIs every day, but it's always nice to have another tool for optimizing your database.
Kevin Forsythe has over 18 years of experience working with the iSeries platform and its predecessors. He has been a member of the DMC team for the past nine years. Kevin's primary responsibility is providing iSeries education, but he also provides customers with project management, system design, analysis, and technical construction. In addition to his technical skills (RPG IV, CL, OS/400, SQL, FTP, Query, VB, Net.Data), Kevin possesses the ability to communicate new and complex concepts to his students. He has been the primary instructor for DMC's iSeries-based AS/Credentials training courses since 1997 and has authored courses such as Advanced ILE, SQL, Embedded SQL, Operations Navigator, and Intro to WebSphere Studio. An award-winning speaker, he has spoken at every COMMON Conference since the spring of 2000.
LATEST COMMENTS
MC Press Online