> Is TDP used in conjuction with backint? Is TDP purchase separately?
No! Please have a look at my posting "Re: TDP for SAP R/3 using Oracle"
Regards,
G. Scheckenbach
http://www.xtelligent.de/team/t_gosc.htm
"Jolley, Bill" wrote:
>
> Is TDP used in conjuction with backint? Is TDP purchase separately?
>
> -----Original Message-----
> From: Prather, Wanda [mailto:Wanda.Prather AT JHUAPL DOT EDU]
> Sent: Sunday, August 27, 2000 10:37 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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: ADSM-L AT VM.MARIST DOT EDU
> 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
|
