- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Loading Oracle question
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-28-2005 11:54 PM
тАО07-28-2005 11:54 PM
In previous migrations, I have always loaded Oracle itself using a CD.
Thanks,
Connie
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-29-2005 12:44 AM
тАО07-29-2005 12:44 AM
Re: Loading Oracle question
when we installed Oracle sw (8i) we took a copy of our test server.
Obviously, you will have to amend your config files, tnsnames.ora , listener.ora, ... to refelct the new server.
Please note, on the test server there is a file oraInst.loc located in /var/opt/oracle that indicates the location for oracle products inventory in case you need to add more products.
Regards
Jean-Luc
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-29-2005 12:56 AM
тАО07-29-2005 12:56 AM
Re: Loading Oracle question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-29-2005 01:31 AM
тАО07-29-2005 01:31 AM
Re: Loading Oracle question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-29-2005 10:40 AM
тАО07-29-2005 10:40 AM
SolutionMake sure to get files in /var/opt/oracle and copy over too (and edit them).
However, if you are moving version 8i (or newer) there is a directory called OraInventory that was laid down (could be in Oracle's home directory, could be in the ORACLE_HOME, could be in ORACLE_BASE, could be in the parent dir of either of the last two.
This directory is FULL of binary files that have your machine name, your instance name, and the path to ORACLE_BASE, ORACLE_HOME, etc.
The files in this directory MUST be updated to reflect the machine name, instance name, etc if you ever want to patch that ORACLE_HOME (and you will want to).
You can accomplish this following a few simple rules:
A) Always use the same number of letters for machine names.
B) Always use the same number of letters for instance names (ORACLE_SID).
C) Always use the same mount point for home directories, (/u01/oracle/product/MYSID, /u01/oracle/product/URSID, etc.).
What you need to go for is the ability to replace strings in ALL of these files (in OraInventory) with the same size strings for another database on another machine.
So:
Source machine: bob
Dest machine: sue
Source ORACLE_SID(and db name): MYSID
Dest ORACLE_SID(and db name): URSID
Source path /u01/oracle/product/MYSID/9.2.0.5
Dest path /u01/oracle/product/URSID/9.2.0.5
So, if you can change all strings in all files from "bob" to "sue" and all strings in all files of "MYSID" to "URSID" then you'll be OK.
Next find a copy of "rpl":
(Excert from rpl with no arguments)
......................
rpl v1.1.1 by Joe Laffey, LAFFEY Computer Imaging.
Visit http:// www.laffeycomputer.com for updates.
,,,,,,,,,,,,,,,,,,,,,,,,,,
I think you may also find it on the HPUX porting archive.
Now after you've copied the OraInventory to the new server, then run rpl on it.
cd $ORACLE_HOME/OraInventory
rpl -R BOB SUE .
rpl -R MYSID URSID .
rpl -R bob sue .
rpl -R mysid ursid .
Note that rpl has a simulated mode on it (so you can see what it wants to do first) with the "-s" switch. I often use it to see if anything even needs changing, and if so, what would be involved.
OK, now, you're ready to go, and you can apply patches to the ORACLE_HOME too.
The bad news - if your server names don't have the same length it's not going to work.
The good news - I think there is a workaround.
I believe that we may have used in the past when one server had a name length that was slightly shorter than the others, and that we could patch it, and it worked as a database just fine.
Suppose "bob" is the source, and "sueellen" is the dest. Just go into /etc/hosts and add an alias to "sueellen" as "sue" (three letters).
From what I've seen about what the hostname is used for (and that's very little) - this should work fine. Of course externally, the host name is important - go ahead and use the real name from the other servers, as long as your tnsnames.ora file lines up to the server's listener.ora file you should be in business.
Lastly, if you've got directory name changes that don't match - you can fake it out along the whole path way with symbolic links and get around it that way.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2006 12:39 AM
тАО11-22-2006 12:39 AM
Re: Loading Oracle question
Connie.