cancel
Showing results for 
Search instead for 
Did you mean: 

syscopy Oracle 9.2/10 Windows IA32/X64, Rel. Enterprise 4.7 Ext.Set 1.10

uta_hedemann
Participant
0 Kudos

For a upgradeproject from SAP 4.7 Ext.Set 1.10, we will change our HW-platform and our Oracle-Release.

Source:

SAP 4.7 Ext. Set 1.10, Kernel 640

Oracle 9.2.0.3

Windows 2000 Advanced/Windows 2003 Enterprise Edition IA32 (32Bit)

Target:

SAP 4.7 Ext. Set 1.10, Kernel 640

Oracle 10.2.0.4

Windows 2003 Enterprise Edition, X64 64-Bit,

(will later be upgraded to ERP 6.0)

Since for the SAP-upgrade we need oracle 10, we could do following

VARIANT 1:

steps:

1) sourcesystem: Oracle-Upgrade 9.2.0.3 -> 10.2.0.4 (via patchset 9.2.06)

2) targetsystem: install new system SAP 4.7. Ext.Set 1.10 and oracle 10 and do a systemcopy with backup/restore method according note 659509.

a) According to Note 899111, there is no standard installation set for R3 4.7 Ext.Set 1.10 on Win Server 2003/X64, so we have to make some modifications and use:


Installation master from R3 4.7 Extension Set 2.0 SR1 CD set which
is x64 enabled
Kernel from R3 4.7 Extension Set 2.0 SR1 CD set
Export CDs from R3 4.7 SR1 CD set

and modify exportcds.xml and packages.xml

b) for installation 4.7 Extset 1.10 with oracle 10 instead of oracle 9, according note 896475 we have to use


Installation master from R3 4.7 Extension Set 2.0 SR1 CD

and make adjustments to packages.xml

VARIANT 2:

1) targetsystem: install new system SAP 4.7. Ext.Set 1.10 and oracle 9:

modifications from note 899111 because of platform X64 (like variant 1: Step 2a) and do a systemcopy with backup/restore method according note 659509.

The possibility of an upgrade to oracle 10 during systemcopy from note 932722 seems to be unpossible, because there are only release <= basis 4.6D and releases based on nw04 SR1 (= WEB AS 6.40) listed, but 4.7. Ext. Set 1.10 is based on WEB AS 6.20.

Has anybody experience or recommendations with this special kind of systemcopy from windows-platforms IA32 ->X64 ?

Kind regards,

Uta

Accepted Solutions (1)

Accepted Solutions (1)

uta_hedemann
Participant
0 Kudos

I just saw in note 960769:

-


On Windows Server 2003 X86_64 (64-bit), you may only use Oracle 10g Release 2 (10.2) software for X86_64 (64-bit) as a database. Note 949116 describes the installation (homogenous system copy) of old products that were not originally released on Oracle 10g Release 2 (10.2). If you want to make the copy using the backup/restore procedure, for which the source database was not yet upgraded to Oracle 10.2, see Note 932722.

-


Does this imply, that if one use the modified install procedure from note 899111, the source db has to be on oracle 10 already or does is only mean, that a productive use from oracle 9 in X64 environment is not supported and direct upgrade to oracle 10 after sap installation is needed ?

confusions.....

markus_doehr2
Active Contributor
0 Kudos

You can do that all in one step. Install the target system as system copy from the source system:

Note 932722 - Upgrade to Oracle 10.2 during a database copy

(you may install 9.2.0.6 before)

Markus

uta_hedemann
Participant
0 Kudos

Hello Markus,

but 4.7 Ext. Set 1.10 is not based on NW 04 SR1, so I don't find any valid section in note 932722. Or am I wrong, because I install with the installation master dvd from 4.7. ext.2 (based on web as 6.40) due to X64-platform and therefore it's allowed according section II (based on nw 04 sr1(kernel 6.40)) ?

Best regards,

Uta

markus_doehr2
Active Contributor
0 Kudos

4.7 is based on WebAS 6.20 (SAP_BASIS 620) for both ext. 1.10 and ext 2.00, both use the 6.40 (or 640_EX2) kernel, so from the methodology both are to be treated identically.

Markus

uta_hedemann
Participant
0 Kudos

Sorry that I disagree, but Ext.Set 1.10 and 2.0 are a bit different, I just looked again into the documentation:

Ext. Set 2.0 is based on WEB AS 6.30 (ExtSet 2.0 SR1 is based on WEB AS 6.40)

Ext. Set 1.10 is based on WEB AS 6.20.

Are you sure, that the KERNEL-Release (6.40) is relevant for note 932722 and not the WEB AS release (would be 6.20 with Ext.Set 1.10)?

-


One additional question:

Is it possible to use this scenario from 932722, if a) SID(sourcesystem) and SID(targetsystem) are different or b) the directory structure on source/target is different ?

Edited by: Uta Hedemann on Apr 28, 2009 9:17 PM

markus_doehr2
Active Contributor
0 Kudos

> Ext. Set 2.0 is based on WEB AS 6.30 (ExtSet 2.0 SR1 is based on WEB AS 6.40)

6.30 never officially existed. If one checks using "System - Status - components" in a 4.72 system, it will have SAP_BASIS 620

> Ext. Set 1.10 is based on WEB AS 6.20.

Yes - as above. The only difference between 1.10 and 2.00 are the application components (SAP_APPL, EA* etc.). The underlying basis is the same.

> Are you sure, that the KERNEL-Release (6.40) is relevant for note 932722 and not the WEB AS release (would be 6.20 with Ext.Set 1.10)?

Yes. Because there exists no kernel 6.30 and kernel 6.20 is out of maintenance.

> One additional question:

> Is it possible to use this scenario from 932722, if a) SID(sourcesystem) and SID(targetsystem) are different or b) the directory structure on source/target is different ?

Means - you want to do a system copy?

Markus

uta_hedemann
Participant
0 Kudos

Hello Markus,

first of all: Yes, it's a systemcopy (because serverchange) and because the old dev system is expected to serve a while as emergency dev-system during upgrade project to ERP 6.0, the SID of the copied system should change during copy)

For Basis/Kernel-releases ExtSet 1.10/2.0: Maybe I found the wrong documentation in sapnet. Unfortunately I have no 4.7 ExtSet 2.0, but I trust you, when you say, it's also WEB AS 6.20. But that's not the point.

Where did you read kernel level 6.30 in note 932722 ?

Q: Are you sure, that the KERNEL-Release (6.40) is relevant for note 932722 and not the WEB AS release (would be 6.20 with Ext.Set 1.10)?

A: Yes. Because there exists no kernel 6.30 and kernel 6.20 is out of maintenance.

I mean this special section in note 932722:


II. Procedure for SAP Netweaver '04 SR1 based products (kernel version 640):
For ABAP server products based on release SAP Netweaver '04 SR1: (Web AS 6.40 SR1), the homogeneous system copy procedure by copying database files is described in the following document:
"Homogeneous and Heterogeneous System Copy for SAP Systems Based on SAP Web Application Server ABAP 6.40 SR1"
This document is available on SAP Service Marketplace at:
http://service.sap.com/instguides ->  Installation and Upgrade Guides -> SAP Netweaver 04 -> Installation -> SAP Web AS -> SAP Web AS 6.40 SR1 and Related Documentation.

As I wrote before, I think, I cannot use 932722, because SID is changing:

I think the following way could be a solution:

1) upgrade 32-Bit-source-DB <S-SID> Oracle 9 to 32-Bit Oracle 10.

2) install 64-Bit-targetsystem <T-SID> with oracle 10 64Bit-Software with

installation master 4.7 extset 2.0.

3) use 32-bit oracle 10-backup from Sourcesystem <S-SID> and restore into

64-environment on targetsystem according homogeneous systemcopy guide

from 6.40. Maybe I have to use startup upgrade/utlirp.sql/utlrp.sql as well for migration to 64-bit ?

markus_doehr2
Active Contributor
0 Kudos

> As I wrote before, I think, I cannot use 932722, because SID is changing:

The <SID> change does not change anything since you install a new system. Whether you use the original or another SID is not relevant.

> I think the following way could be a solution:

> 1) upgrade 32-Bit-source-DB <S-SID> Oracle 9 to 32-Bit Oracle 10.

> 2) install 64-Bit-targetsystem <T-SID> with oracle 10 64Bit-Software with

> installation master 4.7 extset 2.0.

> 3) use 32-bit oracle 10-backup from Sourcesystem <S-SID> and restore into

> 64-environment on targetsystem according homogeneous systemcopy guide

> from 6.40. Maybe I have to use startup upgrade/utlirp.sql/utlrp.sql as well for migration to 64-bit ?

It's not necessary to install a complete system and then overwrite the database with your backup.

I would

1) upgrade source system to a version from which an upgrade to Oracle 10.2 can be done (so at least 9.2.0.6 - or better 9.2.0.8)

2) install 64bit target system but not as installation but as system copy. After the central instance installation I would update the database to the latest patchset (10.2.0.4) and apply all interim patches. I'd exchange the default kernel from the DVD with kernel 640_EX2 which is linked against the Oracle 10g client. There is no installation DVD for 640_EX2 kernel so this step has to be done manually. You also need to update then the Oracle instantclient.

3) backup the source system and use the procedure described in the note (for NW 04) to copy the 9.2 database and create control files.

4) "startup migrate" and upgrade the database manually (as described in the database upgrade guide) - not using dbua

Markus

Answers (4)

Answers (4)

uta_hedemann
Participant
0 Kudos

For everybody interested, see also metalink:

Doc ID: 369644.1: Answers To FAQ For Restoring Or Duplicating Between Different Versions And Platforms


Q: Can I restore or duplicate my previous version database using a later version of Oracle? 
A:
...
Once the restore / recovery is completed you will need to open the database with a combination of the resetlogs option and the upgrade option. For example:
SQL>  alter database open resetlogs upgrade;

After the database is opened in this fashion run the upgrade steps for the higher version.
....

further details in metalink-doc...

uta_hedemann
Participant
0 Kudos

Hello Markus,

when I use the dbua for upgrade ( from normal sap oracle upgrade guide), do you agree, that the following steps from note 93722

- orapwd

- remote_login_passwordfile

- upgrade with perl-script remotedbua

are not necessary? In the targetsystem the db-user should belong to the right group, so remote authentication should not be necessary ?

Here again all the steps with some more details:

1A) upgrade source system to a version from which an upgrade to Oracle 10.2 can be done (so at least 9.2.0.6 - or better 9.2.0.8)

1B) check prerequisites for source db from note 93722 4):

- activate AUM

- set autoextend on for system-tablespace

- increase shared pool_size

- delete log_archive_start

1C) check the prerequisites from upgrade guide - chapter planning, too:

- 1. You check the SAP System prerequisites

- 2. If required, you migrate to automatic undo management

- 3. If required, you stop Statspack reports

- 4. You check the SYSTEM and SYSAUX tablespace for freespace

- 5. If required, you check for invalid database objects

2) install 64bit target system but not as installation but as system copy.

After the central instance installation I would update the database to the latest patchset (10.2.0.4) and apply all interim patches.

I'd exchange the default kernel from the DVD with kernel 640_EX2

which is linked against the Oracle 10g client. There is no installation DVD for 640_EX2 kernel so this step has to be done manually.

You also need to update then the Oracle instantclient.

3) backup the source system and use the procedure from homogeneous system copy guide 6.40 to copy the 9.2 database and create control files.

Delete "alter database open resetlogs" from control.sql.

Execute control.sql which creates new controlfiles.

4) upgrade db with DBUA like written in SAP oracle upgrade guide 10g

5) alter db open resetlogs (because of systemcopy)

6) note 932722:

create empty control.sql (startup+exit), because work is already done.

6) start sapinst again until finished

7) follow-up manual activities like usual: SE06, BDLS, deleting entries from tables MONI, PAHI, etc.

I will cross my fingers and hope the best.

Edited by: Uta Hedemann on Apr 29, 2009 5:03 PM

markus_doehr2
Active Contributor
0 Kudos

> when I use the dbua for upgrade ( from normal sap oracle upgrade guide), do you agree, that the following steps from note 93722

> - orapwd

> - remote_login_passwordfile

> - upgrade with perl-script remotedbua

> are not necessary? In the targetsystem the db-user should belong to the right group, so remote authentication should not be necessary ?

Yes.

> Here again all the steps with some more details:

<...>

Sounds really good. Rather complex procedure but it's worth trying. I'd do that on a test system first

> I will cross my fingers and hope the best.

Me too - get back if there are any issues.

Markus

uta_hedemann
Participant
0 Kudos

ad 2) Sure, I also want to do an installation as systemcopy and not fill the database and throw it away afterwards

ad 3) Which note do you mean ?

ad 4) In sap oracle upgrade guide 10g there is only the upgrade with DBUA. You probably mean documentation from metalink ?

- Complete Checklist for Manual Upgrades to 10gR2 (Doc 316889.1)

- https://metalink2.oracle.com/metalink/plsql/docs/10g_Upgrade_Companion.pdf

- etc.

A question for the copy-process: in the homogeneous system guide 6.40 is the information, that ORABRCOPY generates the control.sql, but WHEN is the control.sql executed ? Is this normally done from sapinst, after the restore was done ?

Systemcopyguide says: restore db WITHOUT controlfiles,

but for step 4) I would think, that the controlfiles should be needed, but alter database OPEN should not be o.k. before the DB is upgraded manually to oracle 10.

Example control.sql:


CONNECT / AS SYSDBA
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE
SET DATABASE "NEW"
RESETLOGS
....
LOGFILE
GROUP 1 (
'D:\ORACLE\NEW\ORIGLOGA\LOG_G11M1.DBF',
'D:\ORACLE\NEW\MIRRLOGA\LOG_G11M2.DBF'
) SIZE 50M,
....
DATAFILE
'D:\ORACLE\NEW\SAPDATA1\SYSTEM_1\SYSTEM.DATA1',
....
'D:\ORACLE\NEW\SAPDATA2\ROLL_1\ROLL.DATA1'
;
ALTER DATABASE OPEN RESETLOGS;

Looks like control.sql has to be adjusted:

In step 3) delete "alter database open resetlogs" from control.sql.

then 4) upgrade db manually and afterwards "alter db open resetlogs" ?

Uta

markus_doehr2
Active Contributor
0 Kudos

> ad 2) Sure, I also want to do an installation as systemcopy and not fill the database and throw it away afterwards

ok

> ad 3) Which note do you mean ?

932722

> ad 4) In sap oracle upgrade guide 10g there is only the upgrade with DBUA. You probably mean documentation from metalink ?

I was mistaken, I was referring to the upgrade from 10.2.0.2 to 10.2.0.4 - forget that sentence about not using DBUA...

> Looks like control.sql has to be adjusted:

> In step 3) delete "alter database open resetlogs" from control.sql.

Yes.

> then 4) upgrade db manually and afterwards "alter db open resetlogs" ?

Yes, exactly.

Markus

uta_hedemann
Participant
0 Kudos

format problems SDN:

Does anybody know, how I can edit a message, if the right part

with the edit-Button is hidden ?

problem solved: Its so simple with scrolling in the browser...

Edited by: Uta Hedemann on Apr 29, 2009 5:01 PM