....Hmm, I have just found this in the documentation;
TDPO_FS
This option specifies a file space name on the TSM server which TDP for
Oracle uses for backup, delete, and restore operations. The file-space name
is a string of 1 to 1024 characters. When setting up this option, do not use
a directory delimiter in front of the filespace name. If this option was set
during TDP for Oracle backup operations, this option must be set during
restore and delete operations. If you have more than one Oracle database,
back up each Oracle target database to its own file space on the TSM server.
The default file space name is adsmorc.
Is this the same as the BACKUP_DIR value you mention to set in the tdpo.opt?
One thing though, if there is a default, why am I seeing the BACKUP_DIR not
set problem??
-----Original Message-----
From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 2:36 PM
To: [EMAIL PROTECTED]
Subject: Re: TDPOracle v2.2 HPUX problem
Hi Matt!
The BACKUP_DIR should be listed in your tdpo.opt. It specifies the client
directory which wil be used for storing the files on your server. If you
list the filespaces created for that node on the server after a succesfull
backup, you will see one filespace with the same name as you BACKUP_DIR.
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines
-----Original Message-----
From: Warren, Matthew James [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 12:27
To: [EMAIL PROTECTED]
Subject: TDPOracle v2.2 HPUX problem
Hello TSM'ers,
A DBA of ours is seeing the following error when trying to perform a backup
using TDPOracle on an HPUX system,
ABOX>/opt/app/blooper9/admin/ABOX/udump $ tail -100 sbtio.log
(10613) OBK-sbt: sbtinit: initializing SBT API
(10613) OBK-sbt: sbtpvt_tfn: BACKUP_DIR not set.
I have checked through TDPOracle documentation and cannot find any mention
of BACKUP_DIR; I am not very au fait with the method used from within RMAN
to start a backup and I have asked the DBA to check to see if BACKUP_DIR is
a value that is needed by RMAN separate from TDPOracle.
In the meantime, has anyone seen this before?
Thanks,
Matt.
-----Original Message-----
From: b290 [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 3:14 AM
To: [EMAIL PROTECTED]
Subject: Archive hangs and Poor Archive Performance at TSM 4.1.2 & 4.2
I'm trying to find out if anyone out there in TSM land has problems with
Archiving file after upgrading from ADSM 3.1.06 to TSM 4.1.2 & TSM 4.2.
There is an process using macros to build DSMC archive statements to archive
files. At ADSM 3.1.06 it ran fine with sub-second response time. Now that
TSM 4.anything is installed the best response time we've seen is 3 seconds,
the worst is 41 seconds. To make matters worse, Archives hang in idle wait
for no apparent reason. We've tried to trace this, but when trace is on,
archive stop hanging in idle wait. It's a problem determination nightmare.
The response from IBM is to use the TSM 4.2 with the filelist option and we
are working hard to implement this.
Does anyone have ANY ideas on what we might do to improve performance while
our EDI techie re-write the process to implement the filelist option?
Any help would be greatly appreciated. This issue has been outstanding for
a month now.
**********************************************************************
This e-mail and any attachment may contain confidential and privileged
material intended for the addressee only. If you are not the addressee, you
are notified that no part of the e-mail or any attachment may be disclosed,
copied or distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have received
this e-mail by error, please notify the sender immediately by return e-mail,
and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its
subsidiaries and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor responsible
for any delay in receipt.
**********************************************************************
