|
I too have been thinking that I've not seen enough performance testingto justify the claims - they all feel pretty theoretical right now. Lots
queries.
The new query engine - yes, that clearly has advantages for many
deal for interactive work - long batch stuff, maybe.
But faster reads because there is no validation there? Probably no big
both DDS-based files and DDL-based tables. At this time I'm inclined to
I'm all for the new capabilities in SQL - and the DML can work against
conversations in LinkedIn groups! And left!
OK, bring on the firearms, y'all - I'm fully protected!! I've survived
should
Vern
On 10/24/2014 12:44 PM, rob@xxxxxxxxx wrote:
I think that the vastly improved data integrity and security of DDL
pointbe a much bigger factor than the improved key indexing. Chuck has a
Mail to: 2505 Dekko Drive Garrett, IN 46738 Ship to: Dock 108 6928N 400Ethat he really wants to see the cold hard performance comparisons.
Rob Berendt
-- IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600
couldOf course, "bigger" is not always better, with regard to theIf you use iNav, you can convert all DDS to DDL. That would help you
modernise quickly and take advantage of the bigger buffer sizes which
gives better performance.
performance of every [type of] application and\or system [environment].
To be clear, "bigger buffer sizes" could just as well give worse
performance; the likelihood increases that the performance effects
previouslybe worse, if the applications using the changed file(s) had not
notor simultaneously been changed from RLA to SQL DML.
I will take this opportunity_to remind_ that conversion from DDS to
DDL is*not* in any way "modernizing" the database. A change that is
effectedrequired, is merely change [for the sake of change]; such changes
implementwithout requirements are likely to expose unforeseen issues.
If there is a feature without support via the DDS, and that feature is
available only with the SQL DDL, then a change specifically to
supportthat feature via DDL would qualify as a valid modernization; e.g.
implementing_surrogate keys_ using IDENTITY columns, for which no
andexists in\via DDS.
There are no special "bigger buffer sizes" that result from a mere
conversion; the Page Size setting defaults are different between DDS
creationDDL, but they can be customized. There is little that comes from that
conversion that could not have been achieved by a change to [the
fromof] the existing DDS-defined files. The one conspicuous difference
SQLthat change, is the potential for read-performance improvements for the
lack of data validation performed on read [per the assumption that all
fromdata was validated on input\write] is one_non-modernization_ benefit
and\orthe change; for that same effect, there is an implicit potential for an
existing dependence on the non-validation effect to be exposed in
applications that use a file that was changed.
Changing from DDS to SQL DDL is best performed only*after* having
converted existing applications from using RLA to using SQL DML, to
prevent some difficulties that might be encountered with existing
perpersisting non-SQL applications from having changed the underlying
database physical *FILE objects into database SQL TABLE *FILE objects;
most notably, Record Format Level Identifiers and Data Mapping Errors
toincreased validation requirements for SQL database objects. Failing to
consider the[se and possibly other] side effects of changing from DDS
testing.SQL DDL can result in issues that were not foreseen or noticed in
toI know of some installations that had implemented such a switch, only
recallfind out afterward that negative effects on some existing applications
required that they back-out the changes... surely at great cost; I
wasseveral specifically, one because an APAR was opened, regardless there
journalingnothing that would be/fixed/ because they were close
d Permanent Restriction (PRS) [increased memory footprint for
sizehad caused performance problems due to implicit Page Size
(PAGESIZE) change; since, the SQL was enabled to set a smaller page
oneto reduce the memory footprint for the non-SQL accesses] and all but
listof the others were incidents of data mapping errors being effected on
input\write that had never been diagnosed before the change to DDL.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
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.