Regarding creating the database files....
If you want to use the "Investigate Data" task (which we generally refer to
as the Performance Data Investigator (PDI)), then you must have the data in
the database files.
This is why the IBM supplied default is yes - create the database files
dynamically.
Sure, you can always create the performance data when you need it, but
dynamically populating the data in the files allows PDI to have access to
the most recent performance data without any additional effort on your
part.
If you are on 6.1 or later and haven't' used PDI, you're missing out on a
great feature in the Navigator web console.
Another post mentioned the cycle interval. I agree that 5 minutes is much
better than 15 minutes. But a shorter collection interval means more data,
particularly if there are a lot of jobs on the partition.
<speaker advert>
If anyone reading this thread is attending COMMON in a couple weeks, I have
a presentation on the agenda, "Best Practices for IBM i Performance
Management" where I will talk about managing your performance data and
Collection Services configuration (and many more topics).
</speaker advert>
Dawn May
dmmay@xxxxxxxxxx
IBM Liaison for the Large User Group,
COMMON Americas Advisory Council, and COMMON Europe Advisory Council
Mobile - 507-251-4376
TL 676-8162, External 720-395-8162
Senior Technical Staff Member
www.ibmsystemsmag.com/Blogs/i-Can/
From: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/13/2015 12:41 PM
Subject: RE: Performance data
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Yes.
I would change the library to one of your choosing (QPFRDATA and QMPGDATA
are/were the defaults) you can store performance data anywhere you want
really.
I would turn create the database files off. You can create the performance
data files any time from the collection object so no need to have them
unless you're going to use them.
Personally I urge everyone to keep at least 14 days of collection objects,
21 or 31 are preferred numbers if there is sufficient space available. The
collection objects don't take a great deal of space, but some folks get
excited about it.
Also I strongly urge folks to back up the performance data on a separate
back up appending to a tape kept just for performance data. Once a week is
sufficient. That way your performance data is backed up if you ever need
it, and you can exclude that data from your normal backups since
performance
data is not needed for a recovery. In a recovery situation do you really
care about performance data, I suspect not, so don't spend the time to back
it up or recover it during the emergency. You can recover it later if it's
really needed.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, April 13, 2015 11:17 AM
To: Midrange Systems Technical Discussion
Subject: RE: Performance data
Via this?
Configure Perf Collection (CFGPFRCOL)
Default interval . . . . . . . . 15.00
Collection library . . . . . . . QMPGDATA
Default collection profile . . . *STANDARDP
Cycle time . . . . . . . . . . . 000100
Cycle interval . . . . . . . . . 24
Collection retention period:
Number of units . . . . . . . 00024
Unit of time . . . . . . . . . *HOURS
Create database files . . . . . *YES
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: "Jim Oberholtzer" <midrangel@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/13/2015 12:10 PM
Subject: RE: Performance data
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob,
Do you only keep two days of management collection objects? (I really
like
to see folks keep at least 14 days worth, 21 days are better) It sounds
like collection services is set up to put the management collection
objects
in QMPGDATA rather than QPFRDATA. Also clearly you don't create the
performance data very often or at all. (a good thing if you don't need the
files for a performance investigation)
QPFR is the performance tools licensed program product library, I would
not
mess with it.
QPFRDATA: I would not clear since that's really an IBM supplied library.
QMPGDATA could be removed as long as collection services is updated to use
QPFRDATA.
QPFRD71001 is a library of user creation not by IBM/MPG so clobber away if
you wish.
--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Monday, April 13, 2015 10:47 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Performance data
I have these libraries on my system:
QMPGDATA
QPFR
QPFRDATA
QPFRD71001
QPFR has a bunch of programs in it.
QPFRDATA only has 4 files in it with a blank last used date. Change date
is
from our system migration.
QPFRD71001 only has a few files in it created back in 09 or 10 with blank
last used dates and change dates from our system migration. Assuming this
is performance data prior to when that system upgraded to 7.1.
QMPGDATA has numerous data queues in it created back in 09 or 10, all with
blank last used dates and the change dates are from our system migration.
It does, however, have several active files. Along with those two huge
active *MGTCOL's.
I realize that everyone's system may differ. Our systems that have been
around forever have an active QMPGDATA and dormant QPFRD* libraries. Our
systems that started fresh with 7.2 do not have QMPGDATA and have an
active
QPFRDATA.
Should I delete QPFRD71001 (been a long time)?
Should I clear QPFRDATA on the top system?
Should I delete the data queues from QMPGDATA that were created 2 or more
years ago and have blank last used dates?
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
--
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.
midrange.com
