Joined: 29 Nov 2002 Posts: 382 Topics: 27 Location: Chennai, India
Posted: Wed Jan 15, 2003 1:57 am Post subject: UW and UR
Hi,
I was going through the manuals on Unit of Work and Unit of Recovery Concept. I was not very clear about the difference between the two. Can someone explain the clear difference between the two. (In both CICS and Batch Environments). Examples will be great.
Joined: 08 Jan 2003 Posts: 28 Topics: 4 Location: india
Posted: Wed Jan 15, 2003 2:16 am Post subject:
Manas
To my knowledge both are the same thing. There might be minor differences. Can you please post the lines from the book that you could not understand?
Regards
Bidpar
Joined: 29 Nov 2002 Posts: 382 Topics: 27 Location: Chennai, India
Posted: Wed Jan 15, 2003 2:29 am Post subject:
Hi Bidpar,
The following are the lines -
Quote:
If we think only of online transactions, the term UR seems redundant. When we
run DB2 in distributed, batch, or TSO environments, however, we lose the
boundaries of the transaction manager. Away from the control of the transaction
manager, if one UW involves multiple DBMSs, then it may consist of multiple
URs. In a distributed environment, a distributed unit of work (DUW) with
multisite updates consists of as many URs as the number of relational DBMSs
that participate in the coordinated two-phase commit process.
In distributed, batch, or TSO environments, URs are one or more UWs that an
application process performs against a database between explicit commit points.
For TSO, batch, and distributed procedures, the logic for when a UW has been
completed and a UR can be signaled is the application
Joined: 08 Jan 2003 Posts: 28 Topics: 4 Location: india
Posted: Wed Jan 15, 2003 4:22 am Post subject:
Manas
the manual says:
Quote:
A unit of recovery is the work, done by a single DB2 DBMS for an application, that changes DB2 data from one point of consistency to another
So this means there can be multiple unit or recovery for a single unit of work if the unit of work involves multiple DBMSs.
Also In case of a single DBMS application, although you can recover one unit of work, you may want to recover multiple unit of work at once and hence the unit of recovery might consist of one or more unit of work. Here unit of recovery is the amount of work you are recovering.
Quote:
A unit of recovery begins with the first change to the data after the beginning of the job or following the last point of consistency and ends at a later point of consistency
The manual says a later point of consistency and not next point of consistency.
Joined: 29 Nov 2002 Posts: 382 Topics: 27 Location: Chennai, India
Posted: Wed Jan 15, 2003 4:38 am Post subject:
Quote:
So this means there can be multiple unit or recovery for a single unit of work if the unit of work involves multiple DBMSs.
Also In case of a single DBMS application, although you can recover one unit of work, you may want to recover multiple unit of work at once and hence the unit of recovery might consist of one or more unit of work. Here unit of recovery is the amount of work you are recovering.
Hi Bidpar,
Basically, as I understand it, UW and UR are concepts which aid a programmer to code such programs in which resources can be recovered in case of any abend. What I am not able to understand is the need and the difference between UW and UR.
Your first line says that - "So this means there can be multiple unit or recovery for a single unit of work if the unit of work involves multiple DBMSs." In such a case, we don't need the concept of Unit of work as we are only going to recover whatever is there in the Unit of Recovery.
Your second line says that - "Also In case of a single DBMS application, although you can recover one unit of work, you may want to recover multiple unit of work at once and hence the unit of recovery might consist of one or more unit of work." In this case also we don't need UW as the unit of recovery is what we are going to recover.
What I mean is that is it not enough to define only Unit of Recovery ( Or Unit of Work) and use that only for recovery of resources. Why do we need to define another term when we don't actually use it.
In CICS, we have just one term LUW(Logical Unit of work) which represents all that is going to be recovered in case of any rollback.
Joined: 08 Jan 2003 Posts: 28 Topics: 4 Location: india
Posted: Wed Jan 15, 2003 5:14 am Post subject:
Let's just say unit of recovery does not exist until you recover the data. You code your program according to unit of work. which is same as your Logical unit of work(LUW) which is nothing but the amount of work between two commit points.
But while recovering you will recover how much you want to depending upon your application and business logic. It may consist of one or more unit of work. Let's say your application has 4 explicit commits. That means there are 5 LUW's assuming the implicit commit points at the beginning and end of the program. Now while recovering you may want to recover until 1st commit point , or 2nd commit point etc. It always ends in a LUW boundary.
Unit of work does not say how much you will recover, it says how much you can recover. unit of Recovery says how much you are going to recover and this is always multiple of unit of work if a single DBMS is used.
For application using multiple DBMSs, you recover the DBMS's separately as the logging and recovery process varies from DBMS to DBMS.So they consist of multiple unit of recovery.
Regards
Bidpar
Joined: 29 Nov 2002 Posts: 382 Topics: 27 Location: Chennai, India
Posted: Wed Jan 15, 2003 7:40 am Post subject:
Thanks Bidpar for your reply.
Quote:
Let's say your application has 4 explicit commits. That means there are 5 LUW's assuming the implicit commit points at the beginning and end of the program. Now while recovering you may want to recover until 1st commit point , or 2nd commit point etc.
Can we really do that. I mean once there is a commit, we cannot really recover it. If out of the 4 commits, 2 have already taken place, we cannot recover what has already been committed. Recovery will only be there untill the last commit by issuing a ROLLBACK command.
Quote:
Unit of work does not say how much you will recover, it says how much you can recover. unit of Recovery says how much you are going to recover and this is always multiple of unit of work if a single DBMS is used.
In this case won't the two(UW and UR) essentially be the same. Practically while coding, if we issue a rollback, then it will automatically recover everything untill the last LUW boundary. Is it under our control on how much can we recover?
Joined: 08 Jan 2003 Posts: 28 Topics: 4 Location: india
Posted: Thu Jan 16, 2003 6:44 am Post subject:
As far as I know rollback and recovery are 2 different things. To recover you need the imagecopy of the tables and then go on applying the log. Rollback is something you have not committed yet and dont want to be commited. You dont recover using rollback command. You rollback using the rollback command. If you confuse between these 2 it will be difficult to understand the concept. You generally do recovery if you have wrongly updated some databases or so. Let's say you have updated the database with an old file instead of running the program with the current file. What you do is take the last imagecopy of the database and then go an applying the log records until a point of consistency is reached from where you can rerun/restart your program. Recovery happens forward from an old point of consistence. Rollback happens backward to the last point of consistence. You donot have control on rollback. But you can always tell upto what point you want to recover.
Regards
Bidpar
Joined: 29 Nov 2002 Posts: 382 Topics: 27 Location: Chennai, India
Posted: Thu Jan 16, 2003 7:07 am Post subject:
Hi Bidpar,
Thanks for your detailed posts.
I got your point regarding RECOVERY and ROLLBACK. But I think that the original post meant recovery to the last committed point only. I mean Recovery and Rollback meant the same thing. If you look at the first post where I had quoted the lines from the manual, it also meant recovery in the sense of rollback to the last commit point only. I don't think it meant recovery from an imagecopy. And anyway, recovery from an imagecopy is used to recover data only. There is no way by which we can recover sepcific updates done in a program. I mean there is no way we can code an application program where we can specify unit of recovery uptill which recovery will be done from an imagecopy. Basically, if you consider recovery from an imagecopy, then the unit of recovery becomes the state of data in the database from one point to another point(regardless of which program is updating it) and has got no bearing on any particular application program or the way in which we code a particular application program.
I think the manual mentioned recovery in terms of rollback only. Please correct me if I am wrong.
Joined: 08 Jan 2003 Posts: 28 Topics: 4 Location: india
Posted: Fri Jan 17, 2003 5:30 am Post subject:
Let's say rollback is a kind of recovery which DB2 does for you. It puts the data in the last consistence state. But if you want to move back further then you can use the recover utility. Each application program uses an unique thread id. From the thread id and the start time of your program you can get the RBA to which you want to recover that tablespace using the log records. You can go thru the utility guide for recover utility for more info. You dont have to code application program keeping in mind the unit of recovery. As long as your unit of work keeps the data in a consistence state, it's fine. Only thing you need to know is you cannot recover upto a point between 2 commit points. That's why the unit of recovery always starts and ends with commit points. But you can choose at which point of consistency(commit point explicit or implicit, quisce point etc) to end. It might contain more than one commit point or UW.
Regards
Bidpar
Joined: 29 Nov 2002 Posts: 382 Topics: 27 Location: Chennai, India
Posted: Fri Jan 17, 2003 5:44 am Post subject:
Thanks Bidpar for all your patience. Now, I get everything. Actually I did not know that you could recover a tablespace to a particular RBA. All I knew was that you could recover only from an imagecopy (Log records was something new to me).
Thanks for all your help. I will go through the Utilities Manual.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
