× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Quick, easy, cheap....pick 2 :)

But since Dan specifically mentioned a process that writes 20M records,
it's possible that adding commitment control to just that process wouldn't
be to difficult.

Charles


On Fri, Jul 14, 2017 at 1:32 PM, Rob Berendt <rob@xxxxxxxxx> wrote:

True, perhaps. We found that buying the LPP was significantly less
expensive than modifying all of our vendor supplied programs to do
commitment control. Or even analyzing modifying which ones to get the
biggest bang for the buck.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 07/14/2017 03:27 PM
Subject: Re: SEQONLY(*YES nnn) recommendations on how big a block?
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



And just to clarify...

"journal caching" offers a big performance improvement for mass
writes/updates to a journaled table.

There's two ways to ensure it is occurring...
1) Use commitment control
2) Buy the LICPGM

Charles

On Fri, Jul 14, 2017 at 1:18 PM, Rob Berendt <rob@xxxxxxxxx> wrote:

Somewhere I had some time trials on
5770SS1 42 HA Journal Performance

Phenomenal difference.

Again, it's an easy install and you've got 70 days to get the key to try
it out. That's probably not the legal promotional way but I think it's
one of those "honest intentions" things.

Pretty much non disruptive unless you like to reinstall PTF's just to
ensure that if any PTF's came out for it you now have the latest and
greatest. Because they sure didn't get applied to it when it was not
installed.
It's one of those confusing things "Yes IBM I am at the latest cume,
hiper
and all groups. However, I've added an option since applying all
those."
Just try to find somewhere in the PTF cover letter where it says that
ptf
such and such was for option ## of 5770SS1. I don't think you'll have
any
luck.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 07/14/2017 03:08 PM
Subject: Re: SEQONLY(*YES nnn) recommendations on how big a
block?
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



pretty sure those values are still valid...

On your application that writes 20M records to a journaled table, are
you
using commitment control?

If not, re-read the book. :) Note that the Journal Caching PPRQ
mentioned
is now a LICPGM..
5770SS1 42 HA Journal Performance

Rob has posted many times in the past that he got more improvement out
of
the journal caching than going to all SSDs.

Charles


On Fri, Jul 14, 2017 at 12:40 PM, Dan <dan27649@xxxxxxxxx> wrote:

In the "General performance considerations" chapter of the redbook
Striving
for Optimal Journal Performance on DB2 Universal Database for iSeries
(SG24-6286-00), it has the following recommendation:

"Specify Sequential Only on OVRDBF
Where possible, use the CL command OVRDBF to specify sequential-only
processing when adding rows to your database tables. Also, consider
using
separate open data paths (ODPs) and open these for output when adding
large
amounts of rows to your database tables.
Also, specify the NBRRCDS parameter with a value as close to
128KB/row-width as possible to maximize memory buffer utilization."

I have tested this, especially since we turned on journaling and
performance on this one application that writes 20M records to a
table,
and
found a signficant boost in performance. But I note that this redbook
was
written 15 years ago and mentions in the edition notes that "This
edition
applies to Version 5 Release 1 of OS/400". Can anyone advise whether
this
particular recommendation, specifically WRT the 128KB/row-width, still
applies today? (We're on Power 8, v7r1.) If I go with a bigger block
than
128KB, at what point do I need to be concerned with resource
contention?

- Dan
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.