RE: Journaling not practical?!?!

The Redbook also contains the recommendation simply to turn on commitment 
control (probably Rick Turner's contribution). The result is to make the writes 
to the journal be asynchronous. This is the same recommendation I refer to in a 
post from a long time ago here, but the link is broken - probably ended up in 
this redbook. There is a PRPQ for journal caching that costs lots of bucks, but 
just starting commitment control effectively does some journal caching - gets 
you a lot of that bang for no bucks. 85% elapsed time reduction is reported on 
page 118 or so of the redbook.

-------------- Original message -------------- 
From: "Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx> 

> I second Charles' recommendation on the redbook. It's the best redbook I've 
> ever read (kudos to Larry Youngren). 
> Of course, I don't remember all of the details, but I do remember the 
> conclusion about performance overhead was about 4% for the customer that was 
> collaborating with the writing of the redbook (don't quote me on the number 
> as I'm pulling it from the back of my head). 
> Actually, I think Larry mentioned there are specific cases where journaling 
> increased performance for some customers! 
> 
> Elvis 
> 
> -----Original Message----- 
> Subject: RE: Journaling not practical?!?! 
> 
> James, 
> 
> Take a look at the "Striving for Optimal Journal Performance" redbook. 
> http://www.redbooks.ibm.com/abstracts/sg246286.html 
> 
> It's a little dated as it's from 2002, but if you want to talk about 
> journal on large systems: 
> 
> "The end-of-day routine executes more than 400 application programs and 
> updates more than 
> 100 of the 2000 journaled tables present in this shop. Banesco has 2000 
> journaled tables of 
> which 100 are heavily modified, all sent to the same journal, which 
> grows by 15GB during a 
> full two hour and 34 minute batch run. 
> 
> The application programs are primarily written in RPG, with some 
> embedded SQL statements 
> and they perform tasks typical to a banking environment, for example 
> calculating interest on 
> savings and checking accounts, updating account balances, and so on. 
> Those batch jobs 
> also populate datamarts which are used in a data warehousing 
> environment. None of the 
> application programs that are executed as part of the end-of-day routine 
> uses commitment 
> control. 
> 
> The end-of-day batch run typically generates in excess of 16 million 
> journal entries in a little 
> over two hours." 
> 
> 
> Unless your customer is running at 95% CPU usage, they should be able to 
> implement journaling with little problem. Depending on their DASD 
> usage, they might need some extra space but that's a small price to pay. 
> 
> 
> 
> HTH, 
> 
> Charles Wilt 
> -- 
> iSeries Systems Administrator / Developer 
> Mitsubishi Electric Automotive America 
> ph: 513-573-4343 
> fax: 513-398-1121 
> 
> 
> > -----Original Message----- 
> > From: midrange-l-bounces@xxxxxxxxxxxx 
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H 
> > H Lampert 
> > Sent: Thursday, March 23, 2006 12:06 PM 
> > To: midrange-l@xxxxxxxxxxxx 
> > Subject: Journaling not practical?!?! 
> > 
> > My fellow geeks: 
> > 
> > We've got a customer claiming that their system is too 
> > big, with too many sensitive files, to journal everything. 
> > 
> > This sounds like a cop-out to me, particularly given that 
> > IBM is actively encouraging users to journal EVERYTHING, 
> > and that much of the SQL functionality won't even deal 
> > with non-journaled files unless you explicitly tell it 
> > it's OK to do so. 
> > 
> > Could anybody suggest how or why this wouldn't be a 
> > cop-out, and/or a polite way to tell them they're sucking 
> > antimatter if they think journaling isn't practical? 
> > 
> > -- 
> > JHHL 
> 
> 
> 
> -- 
> 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. 
>