RE: Reference to DBA Question

It's a brilliantly researched article, in which the author shows quite
clearly that it makes a difference whether you create your files with
DDS or DDL.

The gist of the story is that DDL-created files, as Alan explained, are
edited when data is written to the database.  The OS treats DDL files
differently, with special integrity checks to ensure that even if you
write to them using evil techniques like CPYF, that bad data won't get
written.  This simple concept basically front-loads data editing,
thereby shifting the load from reads to writes.

If your application fits the author's idea of a normal profile (and I
think most do), with reads greatly outnumbering writes, then the overall
effect will be a reduction in I/O wait time, especially on heavy reads.
You'll probably want to profile your applications to make sure this
makes sense in your environment.

Note that this has nothing to do with SQL vs. native I/O in your
business logic.  Both native I/O and SQL get the same effects from
DDL-based files.  Writes are slower, reads are faster.  The only real
downside is the size of the paging buffer for DDL files, which is 64K as
opposed to the standard 8K of a DDS logical.  If you are already memory
constrained, you will be further constrained, and the additional paging
could very well cancel out any benefits.

There are additional points in the article centering on access paths;
there is now a specific order to create logicals and also to use shared
access paths.  Again, the memory issues apply.

Joe



> From: Alan Campin
> 
> Don't know how many people still get Iseries Network but they had an
> article in the May 2005 issue concerning performance between SQL
defined
> and DDS files.