|
Look at the list of files, journaled into QDBJRN. As I said before, QDBJRN services QADB* files, so it receives lots of entries if these files are being updated. This can be file creation/deletion, but also creating/removing constraints, stored procedures, SQL packages, SQL user-defined types and functions, etc. If you have lots of activity in this journal, you should also see increased activity from QDBSRVn jobs. Try to understand what's causing it. These messages by themselves are not a problem - system normally does not require any management of this journal. You do not need to keep receivers for this journal on system - and do not need to save them. In fact by default it's set to delete receivers. I think, default threshold for this journal is 15000K. You may want to increase it, then you will get fewer messages. Best regards Alexei Pytel System Performance III Dept XQK/006-2 Rochester, MN (507) 253- 2867 or T/L 553-2867 Internet: pytel@us.ibm.com VM mail: IBMUSM07(PYTEL) "Pessimist is nothing but a well-informed optimist" fiona.fitzgerald@notes.ro yalsun.com To: <MIDRANGE-L@midrange.com> Sent by: cc: owner-midrange-l@midrange Subject: Re: QDBJRN increased activity .com 05/09/2001 04:39 PM Please respond to MIDRANGE-L Thanks, Alexei, I'm very familar with the journallling process; my concern is that we haven't had this escalated creation of journal receivers before for a Qrecovery library. We've encountered it during Y2K & Euro testing, where vast amounts of (copies of) production files were being updated at weekends, and the test -journalling spiralled. I interpreted this having as a known cause & the decision was made, not to resize the receivers, as it was an atypical growth, but to suspend journalling on some files & delete receivers as we went along on most. So now I see it happening again, & this time populating a journal in QRECOVERY. My concerns are; - What's causing the increase & how can I tell ? (What kind of objects are affected - does it warrant a change in system administration & monitoring) - If the changes are being stored to facilitate recovery of part of the DB, should we be throwing receivers away so fast ? (System-managed, delete on chgjrnrcv, threshold is currently 5,000, so the receivers are being zapped faster than they could be backed up) All suggestions gratefully received, Thanks, Fiona +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
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.