cancel
Showing results for 
Search instead for 
Did you mean: 

SAP Upgrade with Oracle Dataguard

former_member229542
Active Participant
0 Kudos

Hi Guys

We are performing an Upgrade of SAP ERP 6.0 to EHP 7 based in Solaris and Oracle 11g.

This is a productive database so its replicated to another server using Dataguard.

My main questions are:

Before entering Downtime when SUM ask to Central Instance to be isolated and have a full Backup, Dataguard should be switched off?

In case it has to be switched off, i would assume it would be switched on after final Backup is performed in Productive and activate replication so both databases (primary and stand-by) are at the same state.

Since Kernel version is upgraded in Primary Server, I understand Dataguard Server should be also have to perform a Kernel Upgrade at the same time Kernel Switch is executed in Active System

Best

Martin

Accepted Solutions (0)

Answers (5)

Answers (5)

Brindavan_M
Contributor
0 Kudos

Hi Simois,

During the SAP upgrade the SAP component will upgrade, during the downtime phase SAP will create shadow system for only SAP component.  About you oracle datagurad no need to switch off, you better take a full backup before going for downtime. SAP will not touch the stand-by database.

Thanks,

BM

former_member204618
Active Contributor
0 Kudos

Hi All,

Sorry to raise this again but we have the same issue.  We've got a production SPS update from SPS 3 to SPS 17 on ERP 6 EHP2 coming this August on AIX.

We also have dataguard configured.  Now we don't have much in way of redo log space about 50GB, and normally we'd turn redo logging off during an update/upgrade however if we do this on this production system, we won't have the redo logs to apply on the DR database.

How would we proceed in this instance?  Is there a way of replicating the changes post update to the DR database without the redo logs?

Thanks

Craig

stefan_koehler
Active Contributor
0 Kudos

Hi Craig,

> Is there a way of replicating the changes post update to the DR database without the redo logs?

Yes, it is called RMAN Incremental Backups to Roll Forward a Physical Standby Database.

Regards

Stefan

former_member204618
Active Contributor
0 Kudos

Hi Stefan,

Thanks very much, that's just what I wanted to here.

Now I know nothing about RMAN, we use backint and TSM, do we need to setup an RMAN catalog to use this method?

Thanks

Craig

stefan_koehler
Active Contributor
0 Kudos

Hi Craig,

> Now I know nothing about RMAN, we use backint and TSM, do we need to setup an RMAN catalog to use this method?

I hope you are using RMAN even if you use BR*Tools and TDP for mySAP/ERP (it is just a BR*Tools parameter) - this has nothing to do with the used MML. However you don't need to setup anything. "RMAN Incremental Backups to Roll Forward a Physical Standby Database" can be used right away. Just follow the documentation.

Regards

Stefan

former_member204618
Active Contributor
0 Kudos

Hi Stefan,

Thanks very much, we don't use RMAN as we didn't set this system up.  We use as I mentioned backint for TSM and this is controlled by an external backup team.

Cheers

Craig

Former Member
0 Kudos

Hi Craig,

Ideally we keep DG down (and archiving off) during SAP upgrades, just to make sure we have a fall back option ready. Worst case we can go and release DR for operations.

If you have enough space to keep archive logs, enough bandwidth to transfer archive logs from primary to standby, OK to have longer outages if something goes wrong (To do backup restore and recovery).....Yes you can keep the DG sync ON so that primary and secondary will get updated/upgraded at same time.

Regards,

Nick Loy

former_member204618
Active Contributor
0 Kudos

Hi Nick,

I understand, however if you keep DG down during an upgrade, how do you then get the standby DB in sync again?  Do you use the option Stefan suggested?

I'd also like to know if we use the RMAN option, what happens to changes during the incremental backup, as the documentation mentions nothing about bringing the SAP system down whilst taking that backup.

Thanks

Craig

former_member204618
Active Contributor
0 Kudos

Hi Stefan,

Do we need to have a level 0 backup before we can use this approach?

Thanks

Craig

stefan_koehler
Active Contributor
0 Kudos

Hi Craig,

> Do we need to have a level 0 backup before we can use this approach?


No. Just do the incremental with the specified SCN and apply it on standby. That's it.

Regards

Stefan

former_member204618
Active Contributor
0 Kudos

Hi Stefan,

This worked a treat, thanks very much.

Cheers

Craig

former_member182657
Active Contributor
0 Kudos

Hi Martin,

Since Kernel version is upgraded in Primary Server, I understand Dataguard Server should be also have to perform a Kernel Upgrade at the same time Kernel Switch is executed in Active System

I don't think you need to do kernel update at the same time when kernel switch is going on at primary one during upgrade,you could do it later by stopping the activities on it & reactivate the system database again in mount state as well by enabling the application of redo logs.

Regards,

former_member182657
Active Contributor
0 Kudos

Hi,


Before entering Downtime when SUM ask to Central Instance to be isolated and have a full Backup, Dataguard should be switched off?

As you've already been aware about the option to enable Archive logs during the upgrade from SUM tool,if you enabled the option then system will generate archive logs even when your source system in execution phase & same logs will be transferred to Data Guard as per configurations of DG & Source system.

For me if you've no space constraint at your end,you could leave DG on .

Regards,

stefan_koehler
Active Contributor
0 Kudos

Hi Martin,

> Before entering Downtime when SUM ask to Central Instance to be isolated and have a full Backup, Dataguard should be switched off?

You don't necessarily need to switch off the redo log transfer. It depends on your (network) bandwidth and requirements of course. You can also just stop the redo apply on standby, so the redo stream is still transferred but not applied until you re-enable it once again.

Oracle Data Guard is completely isolated from SUM upgrade activities.

Regards

Stefan