Conference decwet::networker

I just tried this command using the next relase of NetWorker, and it
 does not show me duplicates. I've got a mix of client initiated and
 savegroup initiated saves in the indexes.

For those client initiated saves, what are you using: save, or SAP?

thanks.

	Well we just use save commands. As you surmised, system gold
	is a SAP db server.

	Do you think this could impact our ability to recover the
	data if we needed?

	We have not had any problems. We only noticed it cause we
	create a weekly report of what we backed up...and as you might guess
	the numbers got very big. Of course the group billing us for
	the service probably think the dups are great...;^)

	I have not verified the install of patches 1-3...I believe
	patch 1 did fix issues with indexes....would you think that
	this could be an indication of an unpatched system?

>  .3   Well we just use save commands. As you surmised, system gold
>	is a SAP db server.
>
>	Do you think this could impact our ability to recover the
>	data if we needed?

  well.... have you actually *tried* to get the SAP database "back" (for
 example, a disaster recovery?).  I'm presuming not, and I'm very glad we are
 having this discussed now, instead of getting a panic IPMT from this customer.
 See discussion below for details...

>  .0   just trying to find out if there should be multiples? The cb for flags
>	would say no to me.

  I agree, I would not expect multiple entries in the mminfo report.

  I suggest that you could start checking various mminfo reports (man mminfo)
  to cross-check the suspicious areas, and use the GUI also, again, to cross
 check (indexes, volumes). Another cross check is to log onto a client, and
 browse the server, since that scans the indexes in real-time, so whatever
 is there is what you could see (either nwrecover, or recover).
   If it comes down to having a report generated that has 2 lines that dup
 each other, then I'd accept it as part of life. If, on the other hand,
 there really are 2 entries in the indexes, I'd start seriously discussing
 an index recovery. If after that cleanup there *still* shows dup's, this is a
 bug, and we need to be told about it.

----------

Back to the SAP vs save of the SAP DB... philosophically, Oracle databases
 want 2 pieces to return to a known point in time: restore, and recover.
 Restore gets the files back from NetWorker, and recover regenerates the
 Database (using those files, typically the log files) to a particular point
 in time.
   SAP tries to help administrators simplify this process by putting a layer on
 top of Oracle. sapdba is supposed to control backups and recovers of database
 stuff, which is why Legato invented backint (interface to SAP & NetWorker),
 and Digital ported it to Digital Unix. 
   If one uses sapdba, one does NOT use NetWorker to schedule saves. 

  Now, lemme see.... if you save the files (say, every day) including the log
 files, and disaster struck, you could restore those files back to disk, and
 you'd have Oracle back to "that day". I just do not know what SAP would do
 at this point. You need to contact the SAP Competency Center, or SAP
 Support and find out. Since they certify only specific things, it is my
 opinion that what you are doing is "not certified" ergo, not supported.
 Further, if you called us, we would be able to demonstrate that the files
 were recovered, thus NetWorker was not the problem, yet this customer could
 potentially be without a Database!!

   On the other hand, if you used SAP interface, sapdba start saves, and
 NetWorker logs them dutifully. On disaster, sapdba will issue the recover
 and run the restore "automagically". Further, any problems??? Call SAP!!  :-)
 seriously - they get paid BIG BUCKS to be ready for this very thing. Also,
 if it comes out thet the SAP interface or NetWorker were the fauilt, we could
 then support you!

   Evaluate what the data is worth, and make the appropriate decision.