I am trying to find out how others are prepared for DR. We are Unix/Oracle shop and running Lawson in ditributed environment with a SAN (seperate Lawson Server and Oracle Server - Oracle data lives on SAN, Lawson is local). We are 8.0.3 env and 8.0.3 apps.

We have got really solid recovery plans in all areas but one. We have a seperate server that is our DR server that has Lawson installed on it. We know that if we had a failure we can recover Oracle and roll it forward back to where we left off (as long as we have the logs, etc...)

The big question is what our options are with GEN - for example, if our server died, we know that we can bring up the DR server and point the config files to Oracle and our data is preserved. However, it seems as if the only option for GEN is to get what last night's backup had and we would not know what jobs were running/what would be in needs recovery/etc...

We have already thought of Lawson on the SAN, but the same problem holds true if you are thinking about TRUE DR options and the SAN craps out.

What are others doing? If the server dies first thing in the morning this is not a real problem - but what happens at 4:30? Our management would not accept having to recover to last nights backup - especially if they know that the data itself is available.

Thoughts? Moving to 9.0 is not an option right now...

You are in much the same situation with your Oracle that your are with GEN. You can only roll forward to the point that you have copies of your archive logs, so if you backed up those logs last night how would you add in any changes made today?

Chances are that you are taking snapshots of those logs and copying them over to the DR server several times during the day. Luckily, you can do the same thing with GEN. The GEN files are relocatable - assuming that your DR server is an EXACT copy of PROD using the same directory paths and the same productlines. Just grab a copy of the GEN files several times a day and replace the old ones on the DR server with the new set.

You still aren't "up to the minute" but you are only as far behind as the last copy - and an hour behind is a LOT better than a day behind..

You are correct - and in WORST CASE scenario where we've lost the SAN altogether and can't get the data off of it, this is true. We do have a script that pulls off logs on a periodic basis for middle of the day DR if we had to do that. We know that it would take a pretty good effort if we had to do that to match up what GEN had (or did not have), which is one of the questions we are trying to work through. We have planned for issues with recovering Oracle if something on the SAN LUN gets corrupted by keeping the logs on a completly seperate enclosure and LUN - so the data and logs are stored seperate and if we lost TWO enclosures at the same time we probably have BIG problems.

We've thought about scripting that would pull GEN info - but have not tested as of yet. Is there any issues with open files, etc... when we pull data during production hours with jobs that are currently executing, etc? Or do we just get what we get?

Thanks for any help?

You could have open file issues with the gen tables if Lawson is running. It caches some of the data for the gen tables in memory, so you will not get those changes at that point in time. The only real and reliable way to get an acurate snapshot of GEN is to do stop lawson and take a quick snapshot. If you have some extra hardware/software, like some mirror'd drives that you can keep GEN on, then you could do a quick stoplaw, break the mirror, startlaw, then take a bkup of GEN from the broken mirror drives, then resync when it is finished. Otherewise, you are kinda stuck with being able to get the Lawson RDBMS data back where you want it and educating the users that the data in Lawson is where it should be, and that GEN may not show any of the update jobs that were processed since the bkup of GEN that was restored. Report jobs can just be processed again if they need the report again or if the print dir's are OK, then do a loadrpts to put them back into prtmgr for them.

The problem we keep banging heads against the wall and that steers us from pulling randon GEN data across is what would happen to a job that was in process when the server crashed that was an update job (especially things like PR197) - if we did not have the correct GEN info then when we brought it back up on the DR server and with a "recent" verion of GEN we would have no way of: 1) knowing jobs in needs recovery, and 2) recovering them...correct? Our recent copy of GEN might not have any info about this job...

What is everyone else doing about this issue? How are you prepared for a server death towards the end of the day? Surely everyone's management can't just accept recovering to the previous night's backup?

Again I ask.. How recent are your archive logs on the DR server? If PROD goes down you can only roll-forward to the last time you copied your archive logs. If you do them at the same time then you have the same roll-forward point.

If you're thinking you'll always be able to recover them from the SAN then you have severly limited your options and set yourself up for a likely failure. Lawson has always said you should backup you DB and GEN at the SAME TIME to keep them in sync.

g'luck!

Because of the GEN limitation, it's been our policy not to have update job run unattended, or scheduled overnight, but our situation can handle that. There have been clients, in the case of the PR updates, that have created scripts to take snapshots of the PR tables prior to the PR197 & 198 processes incase of an unrecoverable abend. At least at this stage, the DB can be restored to this point and PR can process again. Until Lawson get's GEN in the RDBMS, this is the struggle that everyone has. Each client has to evaluate how and to what point a Disaster Recovery can get them back to as close as it can to the point of failure. A failure will (in most cases) have different methods of recovery and possibly to different points in time depending on when during the day it happened, what type of processing has happened prior to and at the time of failure and how critical it is to: 1 - have the data recovered to that point, and/or 2 - how critical it is to have GEN synced with the data. It's just an unfortunate situation we clients have to determine what is best for us, explain the limitations and hazards if unmonitored update jobs are processed when a failure may occur, and have the decision made ahead of time that if it isn't 100% certain of what was occuring at the time of failure, is it worth the risk not to have GEN sysnc'd or play it safe and restore to the point of a good bkup and process forward to get caught up.