|
Sure, Ryan. I meant that SQL is not optimized - my pronoun did not point to the right object. ODBC does let you read a row at a time from a result set, but this does not make the fastest way to do that. ODBC is a front-end, basically, to SQL, and SQL is best with sets of records, not single records like the native IO we use in RPG. Hope that clarified what I meant. ;-) Vern -------------- Original message -------------- From: "Ryan Hunt" <ryan.hunt@xxxxxxxxxxxxx> > Vern, you caught my interest with your statement, "and it [ODBC] is not > optimized for single record access the way native IO is". > DB2/400 is a secondary skill for me...can you elaborate on that? > > > wrote in message > news:041020061936.16276.443AB3B7000DB75E00003F942207020853099D0A0D030E0890@comca > > st.net... > > As Pat says, lots of logicals will hurt. Every LF needs to update the > access path for every change to the PF, and all that takes up CPU cycles, no > matter what. One thing to do is what Pat suggests, to delay access path > maintenance (the MAINT parameter of CHGLF, I think) for LFs not used often > (End of year only processing, e.g.). Another technique is to maximize > sharing of access paths. I believe one way to do this is to SAVOBJ of all > the logicals, then delete them, then RSTOBJ - the system will restore things > with optimal sharing, IIRC. But others should chime in here, as it has been > a while. But non-sharing means extra DASD taken up, which eventually also > means poor performance. > > > > Sorry to repeat, but Centerfield's database/ASSESSMENT does a lot of this > heavy lifting for you. In addition to the database monitor parts, it > analyzes all this access path impact stuff, including file usage, and can > give you good recommendations. It used to include a live discussion with a > solid DB expert there, so it can be worth the few K it costs. > > > > As for ODBC, that is not an IBM idea - it is an open standard. ODBC is not > the culprit here, IMO. There is an excellent piece somewhere at > www.iseries.ibm.com/access on optimizing ODBC performance. A person can > really do it wrong - e.g., using the JET database engine in VB instead of > other methodologies results in deep doodoo performance problems. And > appropriate indexes always make it work better. Remember, ODBC is an SQL > access method, hence you suffer the black box problem that has been > discussed here before - and it is not optimized for single record access the > way native IO is. But an alternative might be to call a stored procedure > with the key values passed, then use native IO in the called program, which > will be lightning fast for that kind of thing. Of course, that is a > pie-in-the-sky answer here, I think. > > > > HTH > > Vern
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.