tag:blogger.com,1999:blog-4516533711330247058.post3673476269000942492..comments2024-03-29T05:35:42.451-07:00Comments on Robert's Db2 blog: DB2 for z/OS: CATMAINT and ConcurrencyRoberthttp://www.blogger.com/profile/02058625981006623480noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-4516533711330247058.post-8145529789831465202018-04-30T16:49:35.259-07:002018-04-30T16:49:35.259-07:00I assume you're asking about what one would do...I assume you're asking about what one would do if one were executing an online Db2 for z/OS migration - meaning, running CATMAINT on one member of a Db2 data sharing group while application work runs on other members - and CATMAINT failed. In that case, one would terminate the CATMAINT process via a TERM UTILITY command, and rerun CATMAINT from the beginning (see CATMAINT information online, particularly the part under the heading, "Termination or restart of CATMAINT": https://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/ugref/src/tpc/db2z_utl_catmaint.html).<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-63271403453390635742018-04-26T08:36:42.456-07:002018-04-26T08:36:42.456-07:00Great!!!! Could you please provide the back up pla...Great!!!! Could you please provide the back up plan if Online migration(N to N+1 fails)Anonymoushttps://www.blogger.com/profile/06235845859607759958noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-87672797078748820762013-11-04T09:45:56.001-08:002013-11-04T09:45:56.001-08:00I hear you. I won't deny that in the real worl...I hear you. I won't deny that in the real world, there are organizations that have run into problems with online migration of a DB2 for z/OS system (and we're talking about a DB2 data sharing group on a Parallel Sysplex -- an outage is necessary in migrating a standalone subsystem to a new version of DB2, because you have to stop the subsystem at the "n" release level in order to restart it as a release "n+1" subsystem). I'll also say this: I work in the real world, with real DB2 for z/OS-using companies, and I know for a fact that organizations have successfully migrated DB2 systems from one version to another without ever stopping the DB2-accessing application workload. Is there some risk in taking that approach, which involves running CATMAINT while applications are accessing data in the system? Yes. What's the surest way to eliminate that risk? Do as you suggest: take a group-wide outage, from a data access perspective (probably don't need more than an hour or two, depending on the size of your catalog), and have CATMAINT be the only thing executing on the system when it runs.<br /><br />If that approach (take the group-wide outage) virtually eliminates the risk of CATMAINT-related problems, why doesn't everyone go this route? Why do some organizations decide to go for online migration? They do that because the importance or truly 100% application uptime for these companies is so important that they will take a migration approach that involves more risk in order to preserve continuous application access data. Obviously, if you decide that this more-risky approach is the one to take, you'll take steps to mitigate that risk: you'll plan the scheduling of the CATMAINT run very carefully (perhaps at a time at which the DB2 application workload volume is at low ebb), you'll ensure that the subsystems in your DB2 data sharing group are current on maintenance (including application of HIPER PTFs), and you'll take multiple steps to ensure that access to the catalog (by people pr processes other than CATMAINT) is minimized to the maximum extent possible (and this would be a factor in the scheduling decision).<br /><br />Bottom line: yes, there is risk involved in online migration to a new release of DB2 (DB2 11 delivers some enhancements in this area). That being the case, take a group-wide application data-access outage (again, it shouldn't be too long) to run CATMAINT, unless even this relatively brief outage would be a serious problem for the business. If it would, you can (and other organizations have) do an online migration. If you decide to do this, put in the time to carefully plan and get all your ducks in a row. And, just in case something goes wrong, have a contingency plan.<br /><br />RobertRoberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-63154549598909985252013-11-03T08:18:05.798-08:002013-11-03T08:18:05.798-08:00Stand by what you wrote as much as you like (and I...Stand by what you wrote as much as you like (and I respect your blogging immensely) - in the real world there are real sites out there that have experienced total outages thanks to catalog contention killing catmaint jobs and then leaving the catalogs in an unknown state - particularly skip level migration to V10 - there's a number of HIPERS in that area. I'd take an outage rather than risk being sacked after a job that should have worked didn't - this is the real world and things go wrong.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-13723326428241321592011-02-17T22:26:01.980-08:002011-02-17T22:26:01.980-08:00I hear what you're saying, Ken, but I stand by...I hear what you're saying, Ken, but I stand by what I wrote. CATMAINT (and CATENFM) is designed for concurrency and restartability. You say you've got to see it, and I'll tell you that there are sites that do this in the real world (referring to the execution of CATMAINT while the application workload is running). Backing up the catalog and directory beforehand is a wise precaution, but I've yet to hear of anyone who has ended up with a corrupted catalog as a result of running CATMAINT and application work concurrently using a recent version of DB2 (Version 8 and up). Note that concurrency of CATMAINT and application work tends to be most important to data sharing users, because they actually can keep DB2 available to application programs through a version upgrade (in a standalone DB2 environment you have to stop and start the one DB2 subsystem anyway to go from version X to version Y). Note also that people who run CATMAINT (and CATENFM) while application work is executing generally try to do that during a period of relatively low application activity -- this to reduce the odds of an application time-out (or a CATMAINT time-out that will require restarting the utility). I'm using the term "restart" loosely here: if CATMAINT doesn't complete successfully, you terminate it and rerun the utility from the beginning. If a terminated execution of CATMAINT leaves some indexes in REBUILD-pending status, we have (in DB2 9 and up) online index rebuild.Roberthttps://www.blogger.com/profile/02058625981006623480noreply@blogger.comtag:blogger.com,1999:blog-4516533711330247058.post-71930332356499577862011-02-17T15:28:03.293-08:002011-02-17T15:28:03.293-08:00Robert,
Well thats "New and Different&qu...Robert, <br /><br /> Well thats "New and Different" -- I'm not sure I like allowing access while I'm updating the Catalog. It sort of sounds like trying to change the Oil while someone's driving the car. Anyway, what happens if the "unthinkable" occurs where user access trashes CATMAINT and you end up with a very unhappy CATALOG (not to mention the Client)? While I have a great deal of faith in the folks from the LAB this one sounds a bit too much like "Magic" to me -- I've got to see this one... <br /><br /> .....Ken HynesAnonymousnoreply@blogger.com