Okay, survey time: 1) Our installation standard it to primarily define queue managers using (a) linear logging (b) circular logging (c) no standard (d) no preference
2a) We selected circular over linear as the standard method because _____ 2a1) Our circular logs can retain ___ days of average message load. 2b) We selected linear over circular as the standard method because _____ 3) I have encountered a corrupt object ___ times in my career. a) ___ were recovered using linear recovery logs. b) ___ were recovered by deleting and recreating the object. c) ___ messages were not recovered from corrupt objects. 4) I clearly understand the real-world difference between linear and circular logging, and can easily explain why one would be chosen over the other in a particular installation: True / False. 5a) All queue managers should always use linear logging; there is no reason to do otherwise. True / False 5b) All queue managers should always use circular logging; there is no reason to do otherwise. True / False 5c) The primary consideration in selecting circular over linear logging should be _________ 5d) The primary consideration in selecting linear over circular logging should be _________ 6a) We process linear logs no longer needed by the queue manager (a) hourly (b) a few times a day (c) daily (d) weekly (e) other ______ 6b) The processing we do is (a) immediately delete (b) retain online and delete later (c) immediately archive offline 7a) We archive and save our expired linear logs for ____ days / weeks / months. 7b) We save the log files to use them for (i) message recovery (ii) object recovery (iii) message audit (iv) problem determination / diagnosis (v) other __________________________________ I apologize if there is some overlap in the questions, but these have been discussions I have participated in over the past year; I think we would all benefit greatly from reading other's views and opinions. On 3/3/08, Potkay, Peter M (ISD, IT) <[EMAIL PROTECTED]> wrote: > I for one am glad to see them say its OK to use circular in that > article. If one uses linear logging for media recovery in case the q > files get damaged, I guess the assumption is that the log files are on > disks that somehow are more reliable than the disks that the q files are > on. But if both q files and log files are on RAID-ed SAN (even though at > the server level they might be / should be on separate mount points) is > that really the case? Its even possible that the volumes on the SAN > frames used for the q files are the same as the volumes used for the log > files. If you can trust the storage to make sure the log files don't get > corrupted why can't you trust the q files the same way and just use > circular? > > Is linear logging a throwback to the days when media was a lot less > reliable? > > I've dealt with damaged q objects once a few years ago. It was a > transmit q. We just defined a new one (new name) and repointed the > channel and the remote queue defs to use the new one until that night > when we deleted the original damaged XMITQ and recreated it, then > bounced the QM. > > I don't understand why media recovery can't be possible in Circular > logs. I'm sure there are technical details under the covers which > prevent it in the current implementation. But if active UOWs can only > span the total number of Primary / Secondary logs regardless of whether > you have Circular or Linear, why can't a QM with circular logging just > issue rcdmqimg itself under the covers periodically and thus have the > info needed for media recovery inside the circular logs? > > > Peter Potkay > > > > ________________________________ > > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Jim Nuckolls > Sent: Sunday, March 02, 2008 10:26 PM > To: [email protected] > Subject: Re: Linear logging / media recovery > > > > Here's what happened to me 6 years ago on a system I had configured to > use linear logging. It could have been a defect for all I know since I > never pursued it. I was running the linear log clean-up script and a > rcdmqimg script as cron jobs on AIX. The object that had become > corrupted was a queue that was not touched over a very long interval. > When it was finally accessed and MQ informed me that it was corrupted I > attempted a recovery. The recovery image was also corrupted. I had to > delete and redefine the object. That experience certainly "tainted" my > once "pure" opinion of linear logging. I now tend to think it is a lot > of additional effort for something that may or may not work depending on > how the planets are aligned and whether or not someone waved some magic > feathers in the direction of the shared disk facility. Perhaps a bit of > over dramatization, but, it underscores the fact that you should have a > "worst case" process in place in case you need it. > > > > Maybe someone in Hursley would care to comment on the scenario I just > described. > > > > Cheers... > > Jim Nuckolls > > Enterprise Systems Integration > > > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Potkay, Peter M (ISD, IT) > Sent: Sunday, March 02, 2008 11:15 AM > To: [email protected] > Subject: Re: Linear logging / media recovery > > > > http://www.ibm.com/developerworks/websphere/library/techarticles/0712_du > nn/0712_dunn.html > > > > "If you need to be able to forward recover queue data following a > failure or recover from media failure of the device containing the log > you must use linear logging if you are dependent on WebSphere MQ to > provide this level of protection for you. An alternative strategy is to > use disk mirroring to mirror the log device. This is often a facility > provided by a SAN. In this case you could use circular logging." > > > > > > Peter Potkay > > > > > > ________________________________ > > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Darren Douch > Sent: Sunday, March 02, 2008 11:29 AM > To: [email protected] > Subject: Re: Linear logging / media recovery > > Aye, but was there anything on that damaged object that needed > recovering, or was it an empty queue that could simply have been deleted > > / redefined? In a 'MQ is not a database' world, surely that would be > the case? > > Note I am not arguing one way or the other here... just after honest > opinions either way. > > Thanks Bobbee. > > Darren. > > > Robert Broderick wrote: > > Damn, I am so glad you just asked this. Timing is everything. > > > > Just was involved in a migration for a customer. Had to come to > > Champaign, Il for the weekend. Aside from all the other stuff they > > upgraded DB2, MQWF, MQ and WMB. In the middle of it the SA running the > > > scripts calls over and sez he has gotten an error code. After some > > looking it was a case of damaged object. My next question was what > > logging were they running. He replied Linear, I replied good boy!!! > > Off we were after one or two commands. > > > > This is the third time in my career that I have relied on the fact > > that there were Linear logs in production. > > > > I wonder which side of the fence I sit on with regards to this > subject. > > > > > > > > > > > ------------------------------------------------------------------------ > > Date: Sun, 2 Mar 2008 08:28:14 +0000 > > From: [EMAIL PROTECTED] > > Subject: Linear logging / media recovery > > To: [email protected] > > > > Presumably lots of people out there use linear logging because > > it's the > > recommended way to operate in 'serious' environments... but how > > widespread is the practice of actually performing media recovery? > > Obviously we are all just using MQ for items in transit - DB2 is > > being > > used for our database requirements ;) so is media recovery really > > needed > > in the real world, or just in theory? > > > > Cheers > > Darren > > > > > > > ------------------------------------------------------------------------ > > Messenger on the move. Text MSN to 63463 now! > > > > > ------------------------------------------------------------------------ > > List Archive > > - Manage > > Your List Settings > > - > > Unsubscribe > > > > Instructions for managing your mailing list subscription are > > provided in the Listserv General Users Guide available at > > http://www.lsoft.com > > > > > > > ------------------------------------------------------------------------ > > Connect and share in new ways with Windows Live. Get it now! > > > > > ------------------------------------------------------------------------ > > List Archive > > - Manage Your List Settings > > - > > Unsubscribe > > > > > > > > Instructions for managing your mailing list subscription are provided > > in the Listserv General Users Guide available at http://www.lsoft.com > > > > > > > > ________________________________ > > She said what? About who? Shameful celebrity quotes on Search Star! > <http://www.msnsearchstar.com> > > ________________________________ > > List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - > Manage Your List Settings > <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - > Unsubscribe > <mailto:[EMAIL PROTECTED]&BODY=sign > off%20mqseries> > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > <http://www.lsoft.com/resources/manuals.asp> > > > > ************************************************************************ > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution > is > strictly prohibited. If you are not the intended recipient, please > notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > ************************************************************************ > * > > > ________________________________ > > List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - > Manage Your List Settings > <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - > Unsubscribe > <mailto:[EMAIL PROTECTED]&BODY=sign > off%20mqseries> > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > <http://www.lsoft.com/resources/manuals.asp> > > > ________________________________ > > List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - > Manage Your List Settings > <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - > Unsubscribe > <mailto:[EMAIL PROTECTED]&BODY=sign > off%20mqseries> > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > <http://www.lsoft.com/resources/manuals.asp> > > > To unsubscribe, write to [EMAIL PROTECTED] and, > in the message body (not the subject), write: SIGNOFF MQSERIES > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > -- _____________________________ David Awerbuch - IBM Certified MQSeries Specialist Bluestar Technologies, Inc. email address: david.awerbuch (-at-) gmail.com To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
