onarchive question

Does anyone have a reason why this is failing:? I execute from onarchive: Onarchive> archive/dbspaceset=alldbspaces/vset=archive_tape/level=0 Where dbspaceset = all non-critical dbspaces. archive_tape = /dev/rmt/0m Then I execute the request. Onarchive> exe/req=45 Executing... Please mount volume JON1 of archive_tape and press < RETURN > ** WRITE ** I hit <cr> Then I get: You have mail (but no other errors come to the console). I check my mail and it says: ARCHIVE/VSET=archive_tape/DBSPACESET=alldbspaces/LEVEL=1/NOAPART/BLOCKSIZE=65536/ NOCOMPRESS/COPIES=1/NOENCRYPT/NOLOG/NONOTIFY/NOCRC/NOTRANSIT/ NOEXPIRY_DATE/NOVERIFY/NOIMMEDIATE/NOAUTOVOP Archive request 00000045 failed. and nothing else. Is there another log file somewhere that tells me more than this? And while I am at it, does anyone know what could be bombing in this archive request? -- Jon Croke jcroke@ibnets.com tel: (781) 372-8225 ironbridge networks inc. [http://www.ironbridgenetworks.com] 55 Hayden Ave. Lexington MA 02173

John, I'm not the most expert person who has ever posted to this group, but I've got some experience with onarchive (something that most folks avoid like the plague). One thing that I notice is that you're using an explicit dbspaceset of alldbspaces... If I read that correctly, you're trying to archive all of your database spaces; if so, use dbspaceset=*. That syntax is a lot easier, and is less likely to cause you problems in the future (forgetting to add a dbspace to the alldbspaces dbspaceset). In your $ARC_CONFIG file, there should be a line that says, activitylog=<SOME_FILE> That file will contain a more complete listing of the messages from onarchive. If you care to post that, or e-mail it to me, I might be able to help you more. In general, onarchive is flakey (IMHO). Unless there is a compelling need to use it, I'd stick with ontape (for smaller databases) or onbar (for larger databases). That said, we used onarchive for several years... and still have some production systems backed up that way... <G> HTH. -- Dan Michaelis Database Administrator dan@kax.com Sent via Deja.com http://www.deja.com/ Before you buy.