We do multiple sessions. Back when we started, ADSM (or the API code - never tracked it down) considered each network interface as having a seperate password, even though the host name was the same and the ADSM node name was the same.
So I went to a never-expire password on ADSM and used backint -f password to store it in the .bki. We actually use the same password for multiple nodes - in our environment we don't need to worry about someone getting to things they shouldn't this way. The other way of handling this would be have different server-name clauses for the different environments; the passwords in the .bki tie to server-name. We starrted doing the copies before SAP, Oracle, or backint supported the process, so our technique is slightly different from the install guide. In essence, when we do a PRD (production) to TST (q/a) copy, we set the TST system up with PRD mount points (unmount/remount the file systems), plug in the proper nodename in the dsm.sys file, and change /etc/passwd so the oracle user is oraprd and not oratst. Then SAP, Oracle, and TSM all think we're restoring the PRD backup onto the PRD system. We do this about 8 times per year with no real problems so far. Tom Kauffman NIBCO, Inc > -----Original Message----- > From: Seay, Paul [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 27, 2001 11:47 PM > To: [EMAIL PROTECTED] > Subject: TDP for SAP R/3 Restores to Different System/SID > > > I have read the documentation on this in the Installation > Guide and still > have some issues. Most notably, changing the password on the > source server > is not a good thing when it is a production server TDP SAP > R/3 node name. > That can interrupt the production operation (redo logs, etc). > The case is > the restore is going to run for 4 hours because it is a 1.5TB > database to > restore. > > We like the password generate option for security reasons, > but recognize > there are limitations when doing cross system restores of any > type. TSM > backint goes through all these gyrations to provide a feature > "-f password" > to store the node password encrypted in the .bki file, yet > does not have a > way to handle the problem. > > A feature is really needed to be able to not interfere with > the production > operation. We do a lot of restores of production to test. > > What is everyone else doing? > > Paul D. Seay, Jr. > Technical Specialist > Naptheon Inc. > 757-688-8180 >
