Geoffrey -- I can't say where you're running into problems, but I can tell
you how everything ties together, which may give you an idea of where to
look.
Brbackup fires up (SAP backup utility) and determines from its parameter
file or command line that you will be using backint (TDP/R3). Brbackup
invokes brconnect to attach to the database and build a list of files to be
backed up (archived, in TSM terms). This is written out in a file in the
/oracle/<SID>/brbackup directory and backint is invoked.
Backint parses the *utl file -- key values at this point are MAX_SESSIONS
which should be 4 from your notes; RL_COMPRESSION - if yes, backagent does
simple run-length compression of the data *before* passing it to TSM;
MULTIPLEXING, which is the number of files to combine in one session; RETRY,
the number of times to retry a session in the event of TSM errors; TCPWAIT,
the number of seconds to wait before assuming a timeout; and the SERVER
stanzas.
The SERVER in the stanzas references your SERVERNAME in the DSM.SYS under
/api/bin; SESSIONS indicate the number of concurrent sessions for this
server. To use multiple network interfaces, code a SERVERNAME for each
interface in DSM.SYS and include a SERVER stanza for each SERVERNAME; the
number of SESSIONS for all SERVER stanzas must be equal to or greater than
MAX_SESSIONS or backint will toss his cookies and quit.
For each session, backint invokes a copy of backagent to actually read the
files, do the rl-compression, and pass the files to TSM by way of the API.
In earlier versions of backint these were seperate processes; it looks like
they are now threads within the backint process now. If. for example, you
specify MAX_SESSIONS=4 and MULTIPLEXING=3 you will get 4 copies of backagent
running, each of which will grab 3 files at a time. These backagent sessions
and this copy of backint exit when all the database files have been
archived. If this was an off-line backup, brbackup starts the database at
this point; if an on-line backup, the tablespaces are taken out of backup
mode.
And then brbackup fires up backint again, for what SAP calls the 'protocol'
files. These eight files total to less than a gigabyte, usually. They are
the log file for the backup (something.anf or .aff); the back<SID>.log of
all backups; the struct<SID>.log; the init<SID>.sap, init<SID>.utl,
init<SID>.dba and init<SID>.ora, and the reorg<SID>.log. The backup is truly
finished when these eight files have been processed.
One thing I've run into is a change between version 2 backint and version 3
regarding rl-compression. In version 2 the process would work on 256-byte
chunks, dropping them to as little as four bytes. In version 3 the chunks
can be up to 2 GB and can compress down to 8 bytes.
I'd check to see if you're running TSM compression now where you weren't
previously; Oracle databases tend to be pretty empty. I use rl-compression
and *still* get a 4:1 compression ratio on my LTO drives at the hardware
level. Check your network topology, and use ftp to see what speed you're
really getting on the transfer.
Hope this helps --
Tom Kauffman
NIBCO, Inc
> -----Original Message-----
> From: Gill, Geoffrey L. [mailto:GEOFFREY.L.GILL AT SAIC DOT COM]
> Sent: Tuesday, July 16, 2002 8:33 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: TDP for SAP
>
>
> It looks as though our SAP backups have ground to a crawl here and I'm
> wondering if anyone else has seen this or might shed some
> light. I'll tell
> you I don't have access to the nodes so it may take me some
> time to get info
> that I haven't supplied here. The slow backups started in May
> I'm told,
> everything was fine before that. The nodes are set up to
> allow 4 connections
> each, and I see this when they attach.
>
> I received the below info from the SAP folks so it's possible
> we've got some
> issues since the hardware changeover. There have also been
> some network
> changes and I've discussed rolling those back to see if
> things return to
> normal.
>
> "I would agree with Don that SAP uses the *utl file -- SAP
> goes through it's
> regular backup tool (brbackup) that then calls the TSM
> provided software
> called backint. As of the time I set up the topes45 box for
> TSM I used the
> latest versions of the software. However, when I spoke with TSM Cust.
> Support, they indicated that we were on the bleeding edge
> with the Compaq
> ES45 hardware and OS 5.1a... ..they said it would work, but
> {fill in per
> your imagination}."
>
> I'm told what's happening is the system screams through it's
> backup in a few
> hours but then takes some 4 to 6 hours to transfer the last few files.
> Sounds like it does a file, then sits for an hour then does
> another and sits
> for an hour and so on till it completes. I'm told these are
> small files,
> less than 1G, compared to the rest of the stuff. I'm also
> told this software
> utilizes something called a .util file instead of a dsm.opt. Is this
> correct? They sent me a copy of the file and see some of the
> same things I'd
> see there, however I still thought it needed it. Someone help
> me out please.
>
> The bottom line is these servers worked before in another
> life. There have
> been too many hardware/software changes which has truly compounded the
> situation to the point where we can't go back a step to start
> over. The OS
> is listed as 5.1a, the TSM baclient is 4.2.0.0 according to
> the TSM Server.
> Total DB size is close to 300GB. The backup starts at
> midnight on Sunday, at
> 5:30, 6:30, 7:30, 8:30 and 9:30 I see these, then at 9:34 the
> backup finally
> completes.
>
> ANR0482W Session 127671 for node XBMS (TDP R3
> Digital)terminated - idle for
> more than 60 minutes.
> 07/14/02 05:30:00 ANR0482W Session 127670 for node XBMS
> (TDP R3 Digital)
>
> Suggestions please?
>
> Thanks,
> Geoff Gill
> TSM Administrator
> NT Systems Support Engineer
> SAIC
> E-Mail: <mailto:gillg AT saic DOT com> gillg AT saic DOT com
> Phone: (858) 826-4062
> Pager: (877) 905-7154
>
|
