Is TDP used in conjuction with backint? Is TDP purchase separately?
-----Original Message-----
From: Prather, Wanda [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 27, 2000 10:37 AM
To: [EMAIL PROTECTED]
Subject: FW: need help in developing a better backup procedure
-----Original Message-----
From: Prather, Wanda
To: 'Lopez, Ulises (ITD) '
Sent: 8/27/00 10:31 AM
Subject: RE: need help in developing a better backup procedure
Hi -
I don't know if this information will help you, but it's something you
could look into:
When you use the TDP agent for Oracle 8, it works with RMAN, the Oracle
Recovery manager. You don't run the TDP agent by itself; you run RMAN,
and it invokes the TDP agent via an API call.
What the TDP agent does is sort of make ADSM look like a funky
alternative tape driver from RMAN's point of view. But instead of going
to a local tape drive, the data goes over the network to ADSM.
As far as I know, your user can STILL specify that RMAN send data to the
local tape drives, or to ADSM, according to which output destination he
selects when he runs RMAN. (And since he will be running the same RMAN
interface he is used to, he should feel pretty comfortable using it.)
(I'm speaking from Oracle on AIX here, don't have any experience with
Oracle on NT.)
Might be worth getting he a trial copy to play with. Has the added
benefit of letting you do backups while the DB is open, which eliminates
all your scripting hassles with shutting the DB's down.....
Wanda Prather
Johns Hopkins University Applied Physics Lab
443-778-8769
-----Original Message-----
From: Lopez, Ulises (ITD)
To: [EMAIL PROTECTED]
Sent: 8/25/00 11:46 AM
Subject: need help in developing a better backup procedure
Hello everyone,
We are running ADSM server 3.1.2.50 under MVS OS/390 2.7
I have a user with high expectations pertaining to ADSM backup
procedures
and I am not sure if ADSM is capable of meeting these demands. Here are
some of the most important demands and concerns my user have:
1. Before backup starts, ensure the machine to be backed up is
active.
2. Prior backup, shutdown databases and have an indicator flag or
return
status code indicating failure or successful of the shutdown.
3. The flag indicator or return code would be use to proceed with the
backup process or stop the backup process and inform Operations.
4. Ability to page, email or both to inform someone about backup
results.
5. The backup process should also provide a return code to proceed or
stop
the process
6. After the backup process completes successful, bring online
database
and return a condition code indicating the status of the database. The
database must be available the next morning.
7. Backup process should produce a report of backed up files or files
that
failed the backup. This information would be used by the on-call
programmer
to troubleshoot the problem and should be available in a single report
and
if possible accessible by remote access (Internet or other means).
8. Operations department should be the centralized location for
initiating
the backup process and information related to backups.
Currently my user have a backup procedure based on MVS TSO meeting most
of
their backup requirements but is affecting the ADSM server due to the
high
number of queries needed to monitor the status of the backups (see step3
below). Following is the description of their current backup procedure.
Step1. Ping the physical machine.
This step is to ensure the machine is active before further actions are
taken. If IP or the machine is not accessible, the job step fails and
no
further action is taken.
Step2. Connect to the Oracle server to bring down the application.
Connect to the application via an Oracle agent. The instance is brought
down once, brought up and brought down again to ensure the instance
would
not have problems at bring up. A return code other than zero would
prevent
further actions on this machine. The reason for using this procedure
instead of the pre/post-schedule ADSM commands is because the script
used
for bringing down the databases could not confirm the status of the
database. There was no indication if the database was down or not. ADSM
executed the script commands and continued with the backup process even
if
the script procedure failed.
Step3. Backup databases using In-house written interface program.
This code was written part Assembler and COBOL and runs under TSO and in
TEST mode. The program performs the following sequence of actions.
a. Logs on to ADSM server as Administrator using TSO Admin
client
b. Defines an immediate schedule for the client using the DEFINE
CLIENTA command to Archive the database files.
c. Queries the server every X number of minutes to find out the
status of the schedule
d. At end of the schedule, queries ADSM Event logs for
additional
information and returns a status condition code.
e. Returns condition code for incremental backup failed files
(ADSM
schedule returns COMPLETED even if there are failed files)
note: We were contemplating using the Tivoli Data Manager for
Oracle
but the user wanted the capability of directing the backups
generated by the Oracle backup utility to go, at their
discretion, to their locals drives instead of always sending the
backups directly to ADSM server.
Step4. Bring up the database. Similar procedure to step 2.
This procedure works for a small number of clients but query overhead
(step3) to the ADSM server is enormous when there are numerous Oracle
clients running backups concurrently. Also, this procedure is dependant
of
TSO and ADSM server may not reside on MVS in the future. Another
problem we
having is when a jobstream is cancelled by Operations or the job
terminates
abnormally, the ADSM server can not remove (DEL SCHEDULE) the backup
schedule left behind by the jobstream and the ADSM server must be
reloaded
in order to remove the schedule.
I would appreciate any good ideas you may have to improve my current
backup
procedure or even better to completely innovate a different backup
approach
as long as my user backup requirements are met. My mind is open for
suggestions.
Thank You, very much.
Note: We are in the process of installing Tivoli Enterprise manager but
I am
not sure if that would help either.
Ulises A. Lopez
Senior Operating Systems Programmer
(305)596-8255
