pacopedro wrote:Hi all,
I have to install SAP 4.7 on sever win AMD64 bit oracle 10.2.
The problem is that I have to do this installation using an export form another sap system but the oracle version is 9.2
How can I do?
I hope you can help me!
If the export was done as a standard Oracle DB dump or via a full database backup , then the general procedure for this is to install a target system via SAPinst, with the full kernel for both SAP & Oracle.
Make sure you patch both to the most recent level applicable, and specially your SAP kernel at least to the same level as the source system (IMPORTANT!)
Also adjust the profile parameters for both components to fit the new server landscape (domain names, ...) and
your old system's memory requirements (-> sappfpar).
The most important point here is that you will install the Target Database as 10.2 outright but will not mount your imported 9.2 DB with anything but mount migrate mode until your upgrade is done!
The internal structure (outside of the dictionary catalog) of Oracle 9.2 and 10.2 is luckily enough mostly compatible.
So you can just restore your existing 9.2 database under a 10.x DB kernel.
The only worry here that a new tablespace called SYSAUX has to be created and when you do that you must follow SAP's BR*Tools naming conventions (or the data files may become unmanageable via BR*Tools later on).
There are a couple of more details to be taken care of, but the general idea is that you start SAP's upgrade script remotedbua.pl
at this time.
That script (which requires a working pearl environment on your system -> Note 932722) then in turn connects to your old database, which has to be up & running and reachable via the network.
Then said upgrade script will connect via a remote Oracle call and retrieve the old DB's data structure and store it in file "fileLocations.txt".
Now you can change the contents of that file to anything
The only thing of importance here is that each and every file system and directory referenced in that file must exist on your local system, or the upgrade script will simply terminate.
Once you've confirmed that all is well, you can continue with the upgrade.
Should the Upgrade Script report back "Error: failed starting database. Please start database in migrate mode and run dbua", then just start the DB with "SQL> STARTUP MIGRATE" and afterwards launch SAP's Upgrade Script again.
The upgrade itself then does nothing else but adjust the DB's data dictionary catalog to fit the new 10.x requirements and creates/moves/deletes some Oracle DB objects around. It shouldn't take any longer than 1-3 hours, even on a very large system (lest we are talking TerraBytes here).
Afterwards you're basically fine, but should still implement SAP's notes dealing with the Oracle DB profile settings and such.
There is an SAP Manual that deals specifically with this procedure (SAP System Migration via Database Restore/Copy procedure
), and you can download it from the SAP Service Marketplace.
: In my above outline, I skipped over a whole host of "small issues", like disabling the user batch jobs, statistic settings and performance issues that Basis Freaks of Nature just take for granted as "being known".
So please consult that manual before you do *anything*, it is very exhaustive indeed (also read the notes it refers to!)
In case you have used SAP tools for the export (-> SAPinst), then you're basically dealing with a bunch of SAP structured database dumps and you can forget about most what I mentioned further up - except for patching your SAP kernel to at least the same level it had been on the source system
You just go ahead and install your target system on Oracle 10.x via SAPinst and use the "System Migration/Copy" method.
It will then just substitute your source system's dump for the one it normally reads from the installation CDs.
So you have to make those dump files accessible on the target system, and since they can grow to considerable size, you have to make sure you get them either physically copied over or you have a reliable (= NOT an NFS based) network connection to the file system they're on.
This procedure is a whole lot easier on your mind than the first one, but the BIG drawback is that the export takes a lot(!) of time, during which the source system must not be worked on.
So it is already difficult to conduct tests with this procedure for live production systems and almost impossible to use it for a one weekend "cutover" project.
ONE MORE WARNING
: While the actual DB upgrade and even the import in the 2nd version doesn't take that much time, do not underestimate the time required to properly prepare everything.
You have to apply patches, notes and adjust parameters. You need to stop and start batch jobs, check DB obects for consistency and structural flaws and adjust statistic gathering procedures (DB procedures).
And then some...
All that will take up the bulk of your time. So start out early in the week preparing your box and then aim to get the actual cutover done over the weekend.