Our main disaster recovery plan is to restore our production system back onto out test system. Full OS restore, full DB restore. We are looking to see if there are any other quicker alternatives. We want to know if it is possible to only have to restore the database by setting up the equivalent /usr/sap/PRD etc. directories on the test system in advance. I recognise that oraPRD and PRDadm accounts also need to be set-up and some of the profile files need to be created specifically for PRD. Would this work ? We are running on Unix.
 

=== On your TST system, install both instances (TST and PRD). When this is done, you can delete the PRD database on your TST system...

If you ever come in a disaster recovery:

you simply stop your TST instance,
delete the database,
rename /oracle/TST to /oracle/PRD
restore your PRD tapes

Read the homogeneous system guide for subsequent steps, do all steps that require a hostname change.

Also make sure that all your SAPLOGONs have entries to this PRD-DRP instance.
 

=== I had the same problem in our company.
So I installed on the test-box also a scond instance (with the same names (disk-drives, directories, ...) - it's a W2003-system.
Then -in case of disaster recovery- we only have to restore the last online-backup , apply redologs (it's an Oracle-Databse), recover the databse - thats rather all.
but still there are some subsequent activities - adapt opoeration modes, TMS, ... (like after every system-refresh PROD > TEST).
 

We have my mistake transported the request from development to production client. Our development & transportation clients are not synchronised. Our account postings have been effected. For past 2 days we are having problems. Anyone please let us know how to do a quick control of the situation... Suggestions, advises, comments are required...
 

=== You cannot really "un-tranport" a request, you can only analyze this transports contents and manually place things the way they were before the transports. You can use version management to undo some of this stuff.
 

== Hard to say something with that brief description... what include the request?.
I suppose you should have stop your operations in the moment, maybe now you have lot of inconsistent data.

If it's customizing try asking in the Functional forums the consequences of the wrong change and how to revert it, if it's possible.

If it's an Abap program, then make another program to reverse what the first one changed... again, if it's possible.

If nothing works, then restore from before of the transport... and recharge all the info of the last 2 days (another big problem).

Good Luck... post some more info.
 

=== Its cutomising request involving the change of offsetting entry to Inventory Posting GBB.
 

=== I don't think there is any choice other than creating a fix in DEV and transporting it over to PRD?
 

How to create a FIX in DEV and transport it to Prod?? What exactly should be done in this case??
 

=== From what I understand your transport from dev, you set the apple cart in the first place so using more transportation will not help. It really is a skilled call. As someone unskilled it may be simplest to restore as suggested. If you analyze the transports also as suggested you can locat the last time each entry was imported, and import these old transports into a dummy SAP system then create a fresh transport from these to import into prod.

... as I said, a restore may be a jolly sight easier.
 

=== Anyway... after all this days I suppose you already applied a solution, but here are some toughts:

- First you have to work in group
- Stop operations
- Select an entry affected by the change
- Reverse that entry
- In DEV reverse the change of the "offsetting entry to Inventory Posting GBB". I mean, if you activate a checkbox somewhere (maybe SPRO), now deactivate it, or viceversa (this should generate a request).
- Transport that request
- Reapplied the entry reversed previously.

If this works without problems now you have to evaluate what's better, reverse all your entries to inventory and reapplied them or restore and reapplied everything, it depends in your workload, modules installed, etc, etc...

As I said this are my thoughts, I suppose there are better ways to evaluate this... I was an abapper now converted to basis with very poor knowledge about customizing.

Read also:
Names of  SAP Standard Admin Jobs

SAP Basis Reference Books:
SAP Basis Components, System Administration, Security, ALE and iDoc Books

Back to Basis Menu:
SAP BC (Basis Components) Hints and Tips

Return to :-
SAP ABAP/4 Programming, Basis Administration, Configuration Hints and Tips