Re: VM for DB2 Backups

O'Brien, Dennis L Wed, 31 May 2006 11:48:14 -0700

Mike,

I think the product you're talking about is LMS/VM. We ran an earlier version here on Windows NT PC's, to talk to a remote STK silo. Service machines on VM talked to the PC's, which in turn talked to a z/OS system that was located in the data center with the silo. It worked, but last year our PC people mandated that everyone get rid of Windows NT. STK proposed a Linux solution, on PC's running Fedora. Our Linux people wanted Redhat. We also asked about Redhat Linux on zSeries. STK said there would be a development effort for Redhat on either platform, for which they would charge us a large sum, and it would be a custom solution. We decided to use an IBM VTS instead.

The only problem we've had with the remote IBM VTS is that we had an incorrect setting in our McDATA (formerly CNT) channel extension boxes, which added a busy status when the VTS generated ATTN interrupts asking the host to collect statistics. The busy status caused VM:Backup to redrive the I/O, resulting in duplicate records on the tape. If you're using a channel-extended IBM VTS, ask McDATA to be sure that setting is off. I don't know if an STK VSM is vulnerable to the same problem. A local VTS from either vendor wouldn't be.

                                                                            Dennis

"History is not a school-mistress. She does not teach. She is a prison matron who punishes for unlearned lessons." -- Vasily Klyutchevsky, Russian historian

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
Sent: Wednesday, May 31, 2006 11:08
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] VM for DB2 Backups

Odd... we're installing a Sun/STK VTS here, and we fully expect z/VM to work with it. Getting it to work is lots more complex than installing RMSMASTR and having VM:Tape work with IBM's VTS. (I used to think *that* was hokey -- live and learn).

The Sun/STK solution is significantly (and needlessly) more convoluted. We have not started the Sun/STK installation on the z/VM system yet (z/OS needs it first, and will get it first), but my current understanding is that it requires PROP (or VM:Operator) action routines, a CMS service machine that talks "IP" to a Linux server. The Linux box will talk over IP to a started task on a z/OS system. The z/OS system started task application talks directly to the Sun/STK VTS. All that to simply get the robot in the VTS to finally move (the actual data will flow over FICON).

Sun/STK tells me that the Linux server should be Redhat (Fedora?) Linux on a Solaris box. I told them no way!; we will install a SuSE Linux virtual machine (just like all the other Linux on zSeries servers we plan) in the same z/VM system that needs access to the Sun/STK VTS. No firewalls. No routers. No problems.

OTOH, Sun/STK will have to support their application in that environment. They want our money, they need to support our environment. We'll see how that all pans out. Man plans, God laughs.

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.

"Moore, Terry A." <[EMAIL PROTECTED]>

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>

05/31/2006 12:51 PM

Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>

To	IBMVM@LISTSERV.UARK.EDU
cc
Subject	VM for DB2 Backups

Our data center is eliminating an STK tape silo and implementing STK's Virtual Tape product. They tell me that there is no interface from VM for STK Virtual Tape. The data center manager wants to know if we could take DB2/VM backups from MVS (shared dasd environment). Our DBA has suggested the alternate solution (below) for DB2/VM backups.

Has anyone got experience with doing DB2/VM backups in such an environment or care to comment on either proposed solution?

Terry A. Moore
Proj Mgr - IT Infrastructure

Terry,
Here is the problem. We have several VM for DB2 database servers. Currently they use vmbackup to take database and log backups using the tape silo. The tape silo is being replaced by a virtual tape machine(from STK). VM cannot talk to the virtual tape machine so utilizing that is not an option. My thoughts currently are to take a weekly backup of all the DB2 for VM database machines data disk utilizing a FAT tape(s) and throughout the week take log backups for the database machines that do online updating. I am still trying to test this scenario to make sure it will work.

Currently, we use a product called VM:DBA from CA that allows us to automate all the backups so no operator intervention is required. In order to use FAT tape(s) to backup all the databases at one time, I will create a vmbackup template that will have all the databases data disks and then it will be submitted via an exec by VM:DBA after all the databases have been brought down. The problem here is VM:DBA will not be able to track when the backups are done and keep track of the volume serial numbers use in the backup process so the restore process will now have to a more manual process outside of the VM:DBA product. Also, a routine to bring the databases back online after the backup is done will need to created.

This message and any attachments are intended for the individual or
entity named above. If you are not the intended recipient, please
do not forward, copy, print, use or disclose this communication to
others; also please notify the sender by replying to this message,
and then delete it from your system. The Timken Company / The
Timken Corporation

The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.

Re: VM for DB2 Backups

Reply via email to