00064 - Backup StrategyPERFORM Short Reference BAL_S_LOG - Application Log: Log header data
This documentation is copyright by SAP AG.
Sorry for the late response but I am answering your 7/24 question for
upgrades. First, remember that in an HA solution only one of the two
Production R/3 System Database servers can be active at any time, otherwise
you place certain tables out of synchronization.
Second, let me summarize the "upgrade" situations, which you will need to
coordinate with the HA solution:
1. Kernel patches - this is a dual maintenance item (execute against
production and backup server) because this operation does not "touch" the
database repository. On the other hand, you could replicate the kernel as
well but one must include the /exe paths that contain the *symlnk for the
programs. IBM never specified this as an area of concern so we have never
focused on it. If you do replicate the kernel, it precludes you from
sharing, which is the case in most Production R/3 Systems that I have seen.
2. "Hot" patches - are applied to the database repository so the HA solution
will replicate these changes to the backup server
3. OS/400 Version/Release upgrade and Cum PTF requiring IPL - as Andrew
Tilbrook described: SAPGUI is redirected to the backup server and business
continues throughout these processes (no more Christmas holidays spent in
the machine room!)
4. Hardware upgrades - same re-direction of SAPGUI to backup server (the HA
solution should handle the reverse replication process transparently)
5. SAP Version upgrade - stop the HA solution from executing. There are
several reasons for this: (1) SAP upgrade process deletes receivers as soon
as they are detached (lose synch point if you need to restart the HA
solution) and (2) if SAP upgrade process corrupts the production server
edition of the database repository, so goes the backup server database
repository. As I said in the previous reason, stopping the HA solution
momentarily and restarting it after the upgrade is out of the question
because the receivers are gone. R/3 is not like other AS/400 legacy
software: everything (SAPGUI presentation text, ABAP software and client
operational data - to name a few) about this application, save for the
Kernel, is placed into the database repository. SAP upgrade is simply one
huge file promotion procedure (my opinion of course). As another responder
mentioned, the table formats are changing in these operations so the
re-direction of SAPGUI is not possible because how does one "merge" the
ongoing transactions currently executing in the old table formats on the
backup server with the new table formats created on the production server?
Hence, the replication process must stop.
Your initial reaction to the HA solution for SAP Version upgrade is "what a
bust!" However, not all is lost; remember the SAP upgrades you have done in
the past and how the process has gone awry and you have had to restore the
original database repository backup that was created prior to the upgrade?
Remember those times? Well in the HA solution, you have a primed Production
R/3 System database repository sitting on the backup server ready to start
and run the business should the upgrade corrupt the database. Once you have
made that determination, you can immediately redirect the business to the
backup server and start the SAPGUI sessions there while you return your
attention to the production server and figure out what went wrong. You will
obviously have to resynchronize the servers in the reverse direction at some
point but that will be a planned process, not under duress. So while you are
not replicating the upgrade real-time (and you really don't want that until
SAP/IBM produce an upgrade process that never fails and pigs fly - just
joking!), you have a nice Plan B should the upgrade fail to execute properly
over a very tight weekend and you do not have much time to recover. This way
you can start the business as scheduled and it is not impacted.
Naturally, a big consideration for the HA solution in any fail-over
situation is that your backup server must have the horsepower (CPU
processing capability) to run all your SAPGUI end-users. However, you could
real-time disable the SAP end-users (requires experienced R/3 Basis
Administrator to be present for every fail-over) or segment your clients
into secondary instances that are considered non-essential during the
fail-over phase (requires one-time effort of experienced R/3 Basis
consultant). When you startup your R/3 System on the backup server, the
secondary instances can remain inactive.
for your consideration,
Fred L. Grunewald
Vision Solutions, Inc.
+1 507 292 9855 direct
+1 507 252 1043 facsimile
888 532 8175 pager (North America only)
----- Original Message -----
From: "Robert Morin" <Robert.MorinZF...>
To: "Sap400 (E-mail)" <sap400Zm...>
Sent: Monday, December 04, 2000 1:06 PM
Subject: Backup Strategy
> Thank you very much one and all,
> For the feedback on the backup strategy, I now have to digest all this
> information and prepare a valid scenario. Now for all of you that are
> operation's (and everybody else is welcome) here is the $1,000,000 dollars
> How do you handle any upgrades????
> Now that's a question to start discussion on a Monday.
> Thanks one and all again.
> Robert Morin
> AS/400 Technical Consultant
> Tel: (514) 694-7710 #5517
Durban Tours - Südafrika Safari
SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up General Data in Customer Master
This documentation is copyright by SAP AG.
Length: 6500 Date: 20231205 Time: 090057 sap01-206 ( 3 ms )