Two thoughts.  Have the BRMS databases been reorganized?   That may in part
be part of the BRMS database performance issue.
I would open a PMR.  It almost sounds like there is the need for some
additional indexes on the BRMS database. 
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Monday, August 31, 2015 8:04 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: BRMS nightly save time differences
High sequence numbers (57793) resulting when using append was the issue.
420 per night, this media set dated back to March 2015.
I broke the media set, had Friday night's save start at sequence 1.
Sat and Sun appended as normal.
All three save times reduced by 20 minutes, equaling the once a week save.
Why would a high sequence number make a difference, it's only an index in a
BRMS database?
Maybe a question for BRMS support.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Thursday, August 27, 2015 1:48 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: BRMS nightly save time differences
Rob and Jim,
All good points.
1) Not sure if default wait time is a variable with SWA.
2) BRMS save uses fast positioning, takes append out of the equation. 
First seq of control group 20 *SAVSECDTA completed within 3 minutes for
both.
3) Sync ID - *none for both 40 *ALLUSR         *SYSBAS     FFFFFFF  *ERR
*YES     QSYSOPR    *NONE     
4) I found two other differences.
	a) nightly save job ENDTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN), while
weekly does not.
	b) nightly and weekly are run by different users.
5) Comparing the joblogs from both nights, I noticed that the longer save is
only seconds longer for each of the 410 libraries saved, gradually gets
longer.
What is the best tool to use for checking/comparing saves, not only times,
but amount saved?
Paul 
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Thursday, August 27, 2015 11:09 AM
To: Midrange Systems Technical Discussion
Subject: Re: BRMS nightly save time differences
Object locks.  Change the job default wait time down to a ridiculously small
interval.
But I did notice that your "different" save is on a Tuesday night.
You could look at the actual joblogs from two different nights to see at
what step the gap started widening.  You may see messages like:
Save-while-active checkpoint processing for library QMGTC complete. 
Cannot use MGTCOL Q01523700 in QMGTC2. 
Save-while-active checkpoint processing for library QMGTC2 complete.
1135 objects saved from MPLUS. 2 not saved.
212 objects saved from QUSRDIRDB. 1 not saved.
280 libraries saved, 3 partially saved, 0 not saved.
Starting save of list *LINK to devices TAPKVL01. 
Message queue LINK not found. 
Object in use.  Object is
  /QIBM/UserData/OS/AdminInst/admin1/wlp/usr/servers/admin1/logs/console.l
  og. 
Cannot open object
  /QIBM/UserData/OS/AdminInst/admin1/wlp/usr/servers/admin1/logs/console.l
  og. 
Object in use.  Object is
  /QIBM/UserData/OS/AdminInst/admin1/wlp/usr/servers/admin1/logs/messages.
  log. 
... 
"Save while active" my sweet Aunt.
Especially since you have the "completed with errors." message.
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:   "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To:     "'Midrange Systems Technical Discussion'" 
<midrange-l@xxxxxxxxxxxx>
Date:   08/27/2015 10:47 AM
Subject:        BRMS nightly save time differences
Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
On our Production LPAR, every night at 22:00, I run a full BRMS save SWA.
Cause . . . . . :   Command to execute is: STRBKUBRM CTLGRP(SAVFULL05) 
  SBMJOB(*NO) APPEND(*YES) ACTIVITY(*CTLGRPATR) RETENTION(*DAYS 45). 
BRM16A1    Diagnostic              40   08/27/15  00:22:55.539417 
Q1AC0SLIB    QBRM        *STMT    Q1ARBK      QBRM        *STMT
Message . . . . :   Backup *ALLUSR, type *FULL completed with errors.
for sequence 57372,
Once a week, same time, we run a different job using the same control group
with different retention overrides and move policies.
Cause . . . . . :   Command to execute is: STRBKUBRM CTLGRP(SAVFULL05)
  SBMJOB(*NO) APPEND(*YES) ACTIVITY(*CTLGRPATR) RETENTION(*DAYS 396)
  MOVPCY(CYCBRC396). 
BRM16A1    Diagnostic              40   08/25/15  00:10:34.356003 
Q1AC0SLIB    QBRM        *STMT    Q1ARBK      QBRM        *STMT
Message . . . . :   Backup *ALLUSR, type *FULL completed with errors.
sequence 18100
The once a week *ALLUSR part of the save is consistently 10 to 15 minutes
faster than the daily save.
During the backup window, no batch jobs, only a handful of interactive
users.
Why would a retention override result in a performance improvement during
the *ALLUSR? 
*ALLDLO and *LINK times are the same.
We do append, sequence numbers are higher for the nightly save compared to
the weekly save.
Thank You
_____
Paul Steinmetz
IBM i Systems Administrator 
Pencor Services, Inc. 
462 Delaware Ave
Palmerton Pa 18071 
610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home 
psteinmetz@xxxxxxxxxx
http://www.pencor.com/
 
 
--
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.
--
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.
--
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.