SAP Maintance with on a standby Databas

[Former Member]

Hello,

have anyone a idea or some documentation how I can use a Oracle standby database to reduce the downtime during some basic maintance tasks like SAP Patch implementation or Oracle patch implemantion?

</p>

</p>

Form my point of view I had the following procedure :

</p>

</p>

- Create a standby Database </p>

- mirror the SAP central instance to another server and configure the mirrored instanze to the standby database (db host etc.)</p>

- configure a logongroup how has access to the "second" central instance and the productive instance</p>

- replicate all data between the productiv database(1) and standby database(2) and switch the standby database to productive</p>

- start the mirrored central instance and deactivate the current productive instance from the logongroups</p>

- perfrom the maintance task , e.g. patch implementation</p>

- perform a redo recovery from the current productive database(2) into the standby database (1) to got all user changes</p>

- stop the mirrored central instance and switch the standby database(1) back to productive</p>

- Switch the logongroupe back to productive</p>

-perfrom a full sync between the productive database(1) (with the new service patches) and the standby database(2)</p>

</p>

</p>Now my question, can I did the redo recovery from the standby database(2) into the productive database(1)? Because during the patch implementation some tables and structures would be changed and I think if I did the redo recovery it would be failed.

Are there any other posibiltys to reduce the downtime during patch implementations?

All opinions would be appreciated!</p>

Thank so far.

Daniel

[stefan_koehler]

Hello Daniel,

to reduce the downtime during some basic maintance tasks like SAP Patch implementation

No way. You can not reduce the downtime of SAP Patching.

or Oracle patch implemantion?

Yes this is possible with a logical standby database, but unfortunately this is not supported in a SAP environment (check sapnote #105047 - Point "16. Data Guard"). Technically it should work.

@Sven:

The sole reason for a stand-by DB should be desaster recovery for production system

That's just wrong. Check the data guard concepts for Rolling Upgrades ([11 Using SQL Apply to Upgrade the Oracle Database|http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/rollup.htm])

The scenario could theoretically work, but only and only if you use your system as a pure reporting system (users only read data)

Yes, but even a SAP BW/BI system writes data during logon, executing queries, etc... so no option here.

Regards

Stefan

[Former Member]

The scenario could theoretically work, but only and only if you use your system as a pure reporting system (users only read data). For example for a simple data warehouse system.

But you can never patch one side and have users changing data on the other side. There is no way to merge this again. You have to stick to downtime minimized upgrades and the like.

Cheers Michael

[Former Member]

Hello Daniel,

your idea to use a stand-by DB is a bit wrong in my opinion. The sole reason for a stand-by DB should be desaster recovery for production system. Therefore a stand-by DB normally has a well-defined delay compared to the actual productive DB so that in case of an desaster the stand-by DB can immediately take over. The advantage is that only those transaction within the defined gap between production and stand-by DB are lost.

Your idea with recovery won't work with SAP patches because you change the repository which is the basis for the whole system. You cannot just ship in some redologs and it will work fine.

And recovering a DB backup from a different release won't work either.

If you really wanna reduce downtimes choose downtime minimized-mode with SPAM while implementing patches for SAP.

Downtime minimizing for patching or upgrading a DB is not possible.

Kind regards,