Thanks Tom ,very nice explanation,

>       René Lambelet
>       Nestec S.A. / Central Support Center 
>       55, av. Nestlé  CH-1800 Vevey (Switzerland) 
>       *+41'21'924'35'43  7+41'21'924'28'88  * K4-117
>       email rene.lambelet AT nestle DOT com
>       Visit our site: http://www.nestle.com
> 
>               This message is intended only for the use of the addressee
> and 
>         may contain information that is privileged and confidential.
> 
> 
> -----Original Message-----
> From: Kauffman, Tom [SMTP:KauffmanT AT NIBCO DOT COM]
> Sent: mardi, 16. juillet 2002 17:13
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: TDP for SAP
> 
> 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
> >