SAP Jobsuche bei DV-Treff


Suchen
zekeman
  • zekeman
  • SAP Forum - Neuling Thema Starter
vor 17 Jahre
Hi,

habe als Neuling eine Frage: Und zwar möchten wir unser R/3 (4.6C) auf einem anderen Rechner aufspielen, doch ich scheitere bereits beim Export der Datenbank (Oracle 9.2). Vielleicht kann mir einer von euch weiterhelfen?!

Folgende Fehlermeldungen bekomme ich angezeigt (bei 80% Fortschritt):


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ERROR 2006-08-11 09:47:55 DBEXPR3LOADEXEC_IND_ORA R3loadPrepare:0
    Child exited with error: rc = 2
    child_pid = 1
    See logfile SAPSDIC.log for further information


ERROR 2006-08-11 09:47:55 DBEXPR3LOADEXEC_IND_ORA R3loadPrepare:0
    Processes started: 15
    Ended with error:  15
    load tool ended with error.
    See above SAP*.log errors.


ERROR 2006-08-11 09:47:55 DBEXPR3LOADEXEC_IND_ORA R3loadFork:0
    RC code form SyChildFuncWait  = 255 .

ERROR 2006-08-11 09:47:55 DBEXPR3LOADEXEC_IND_ORA R3loadFork:0
    See logfiles SAP*log and EX*log for further information.

ERROR 2006-08-11 09:47:55 DBEXPR3LOADEXEC_IND_ORA InternalInstallationDo:0
    R3loadFork erred

ERROR 2006-08-11 09:47:55 DBEXPR3LOADEXEC_IND_ORA InstallationDo:0
    Phase failed.

ERROR 2006-08-11 09:47:55 Main :0
    Installation aborted.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Das SAP Net gibt dazu leider so gut wie gar nichts her. Transportlandschaft ist eingerichtet und es wurde bereits fleißig transportiert...

Hat jemand 'ne Idee?


Peter
Förderer

jmen
  • jmen
  • SAP Forum - Guru
vor 17 Jahre

Hallo zekeman,

R3loadFork erred lässt darauf schliessen, dass der Prozess R3load nicht forken kann, d.h dass hier ggf. eine Haupspeicherengpass vorliegt. Was 'sagt' denn die SAPSDIC.log?

Was hälst Du davon, die DB-Tablespace im offline-Modus von Host A nach Host B zu kopieren, und nicht über Export zu arbeiten? Oder ist die Datenbank der heterogene Anteil? Wenn es nämlich nur eine andere Hardware ist, dann haben wir es hier mit einer homogenen Kopie zu tun.


Gruß

jmen

zekeman
  • zekeman
  • SAP Forum - Neuling Thema Starter
vor 17 Jahre
Hallo jrmen,

upps ganz vergessen zu erwähnen: Der neue Rechner hat ein anderes Betriebssystem, nämlich Windows gegenüber "unserem" AIX. Damit komme ich wohl um die heterogene Kopie nicht herum

Am Speicher liegt es wohl sicher nicht, der Paging Space ist nur zu 9%(!!!) belegt. SAP sagt das es evtl. an der nicht vorhandenen Tabelle E070L liegen könnte. Problem ist, die gibts und es steht auch noch was drin.
Ich bin mit meinem Latein wirklich am Ende...


Grüsse

Peter
jmen
  • jmen
  • SAP Forum - Guru
vor 17 Jahre

Hallo Peter,

zwar migrierst Du von einem Betriebssystem auf Windows, aber Du migrierst nicht die DB. Somit kannst Du doch im Offlinemodus die Tablespaces auf den neuen Host kopieren. Was hat die Tabelle E070L mit forkenden Prozessen zu tun? Die ist für TMS. Hier böte sich doch wirdklich eine Kopie der Datenfiles an.

 


Gruß

jmen

zekeman
  • zekeman
  • SAP Forum - Neuling Thema Starter
vor 17 Jahre
Hi jrmen,

das mit der Tabelle habe ich nur als Hinweis gebracht, da im SAP Service Marketplace hierzu eine Meldung zu meinem Fehler gefunden habe. (hinweis #412423) Hat natürlich nix mit dem Speicher zu tun...

Die Tablespaces kopieren hört sich gut an. Kannst du mir kurz erklären auf was ich achten muss? Kann man die Files so ohne weiteres kopieren und problemlos in eine fremde Datenbank einfügen? In dieser Richtung habe ich leider keine Erfahrung.
Vielen Dank für Hilfe!


Grüsse
Peter
jmen
  • jmen
  • SAP Forum - Guru
vor 17 Jahre

Hallo Peter,

die Datafiles kannst Du problemlos von A nach B kopieren, es muss folgendes beachtet werden:

1. auf der Quellmaschine muss eine File zum Generieren des Controlfiles ereugt werden:
SQL> alter database backup controlfile to trace;

2. das entandene File liegt unter ../background/usertrace/*trc und muss nun in [beliebig].sql umbenannt werden

3. Anpassen der Datei beliebig.sql
-- alles löschen bis zu "STARTUP MOUNT"
-- in der zweiten Zeile: "REUSE" -> "SET"; "NORESETLOGS" -> "RESETLOGS"
-- alle Pfade ändern "/oracle/SID/.." -> "D:\oracle\SID"

4. alle Verzeichnisse aus /oracle/SID werden nun auf die Zielmaschine kopiert.

5. die Datei beliebig.sql muss auch auf die Zielmaschine.

6. Erzeugen des Controlfiles bei heruntergefahrener DB

SQL>shutdown (falls nötig)
SQL>@beliebig
SQL>alter database open resetlogs;

7. Das war's schon.


Gruß

jmen

OldSAPGuru
vor 17 Jahre
zekeman schrieb:

Hallo jrmen,

upps ganz vergessen zu erwähnen: Der neue Rechner hat ein anderes Betriebssystem, nämlich Windows gegenüber "unserem" AIX. Damit komme ich wohl um die heterogene Kopie nicht herum



Dann wirst du aber noch den entsprechende Service bei der SAP AG einkaufen müssen, sowie jemanden, der dir das ganze "absegnet" (jemand, der diesbezüglich auch zertifiziert ist)....

Ciao, OldSAPGuru
.: Technical Consultant for SAP System R/3, Release 4.x:|: Technology Consultant for SAP NW'04 - OS/DB Migration for SAP systems :|: Microsoft Certified Professional :.

.: SAP BC/NetWeaver [ Installation :|: Releasewechsel :|: Systemkopien :|: Systemmanagement ] :.

.: Betriebssysteme [ LiNUX :|: UNiX :|: WiNDOWS ] :.

.: Datenbanken [ DB2 :|: MaxDB :|: Oracle ] :.

gberndt
vor 17 Jahre

Wenn ich die ganzen Schritte beherrsche, warum muss ich mir dann bei der SAP AG einen zertifizierten Berater einkaufen? SAP kann ja noch seine Going Live Checks machen. Die sind Teil der Supportpauschale und bei 1 (oder 2?) heterogenen Systemkopien im Servicebetrag enthalten. Ich muss meine Migration halt recht früh (so 2 Monate vorher) anmelden, damit die Service Sitzung bei SAP terminiert wird.

So hat es bei uns vor einem Jahr gut funktioniert.

Grüsse

Gberndt

OldSAPGuru
vor 17 Jahre
gberndt schrieb:

Wenn ich die ganzen Schritte beherrsche, warum muss ich mir dann bei der SAP AG einen zertifizierten Berater einkaufen? SAP kann ja noch seine Going Live Checks machen. Die sind Teil der Supportpauschale und bei 1 (oder 2?) heterogenen Systemkopien im Servicebetrag enthalten. Ich muss meine Migration halt recht früh (so 2 Monate vorher) anmelden, damit die Service Sitzung bei SAP terminiert wird.

So hat es bei uns vor einem Jahr gut funktioniert.

Grüsse

Gberndt



Ganz eingfach: Ich habt im Zweifelsfall keinen Support, weil: offizielle Lesart der SAP AG (siehe Alias OSDBMIGRATION -> FAQ):

sap.ag schrieb:

Do I need a Migration Check from SAP in every case?

If you plan to use the target system as a production system, you need to use the Migration Check, otherwise SAP cannot give you support. You do not need the Check to migrate development or test systems. Also, you do not need the Check to migrate a production system for pure evaluation purposes as long as you don't use the target system as a production system later.

If you want to migrate a system without involving a certified consultant, then you do this on your own risk. Any support for the migration and for problems that result from the migration will be billed as consulting. This applies also for non-production systems. You are obliged to let a certified consultant perform the migration.

sowie:

sap.ag schrieb:

I want full support from SAP for my migration – what must I do to get it?

If you plan to use the target system as a production system, you need to use the Migration Check. Also, to migrate any SAP system at all, you must secure the services of a technical consultant with special certification for OS/DB migration (through SAP training course TADM70). The consultant must perform the migration onsite. If SAP hotline support is required, the consultant is the contact person.



Hab ich mir ja nicht ausgedacht...

Ciao, OldSAPGuru
.: Technical Consultant for SAP System R/3, Release 4.x:|: Technology Consultant for SAP NW'04 - OS/DB Migration for SAP systems :|: Microsoft Certified Professional :.

.: SAP BC/NetWeaver [ Installation :|: Releasewechsel :|: Systemkopien :|: Systemmanagement ] :.

.: Betriebssysteme [ LiNUX :|: UNiX :|: WiNDOWS ] :.

.: Datenbanken [ DB2 :|: MaxDB :|: Oracle ] :.

Benutzer, die gerade dieses Thema lesen