How best to move oracle9 db and binaries between similiar unix servers?
Ian
another. Both servers have similiar hardware and are at the same O/S
level (AIX4.3.3).
Our change window is short so ideally we would simply like to tarball
$ORACLE_BASE on Server A and untar on server B.
Does anyone have experience with this approach? Is this method
supported? And is there any documentation available specifically
describing the files and directories the rdbms accesses outside of
$ORACLE_BASE such as the ones in /etc/ and /usr/local/ .
thanks very much
Sybrand Bakker
The method you describe isn't supported. I verified this with Oracle
support once.
Assuming server B isn't running production dunno why you just can't
install from CD.
The files located in /etc and /usr/local/bin are of course described
in the AIX documentation. Why are you asking the obvious?. Seems like
you don't know what you are doing or don't have any Oracle experience.
Sybrand Bakker, Senior Oracle DBA
To reply remove -verwijderdit from my e-mail address
Peter Sylvester
Don't know about AIX but I've done this sort of thing in Solaris and
Windows environments (Solaris->Solaris, Windows->Windows) for dev/test
setups. Not sure I'd recommend it for production though.
You need to have same architecture boxes and same OS/Patch level, and
keep the original directory locations.
The unix user/group IDs need to be the same too.
For Solaris you will need to tar/untar as root to keep the setuid
permissions.
The Windows copy is a bit dicey, with registry entries and services, but
can be made to work.
Don't know if any of this would be supported by Oracle (not likely).
--Peter
Jeff W
You should have ample time to set up your second environment by completing
an installation via the Oracle CDs before your window of opportunity. What
is the purpose of the second server? Production? Backup? Based on your
business need, that should help you pick the best way to move data to
another machine.
Thanks.
Jeff
"Ian" <ia...@shaw.ca> wrote in message
news:23b28adc.03071...@posting.google.com...
Ian
production machine. This production server already contains Oracle7
and we don't feel comfortable firing up the Oracle9 installation
outside of a change window. Hence why we are looking at other options
such as restoring the $ORACLE_BASE tarball from Server A into an
Oracle9 $ORACLE_BASE directory on Server B ( obviously different from
Oracle7's $ORACLE_BASE). This procedure could be done almost anytime
as we know those tarball files would not interfere with Oracle7's
files. The change window to migrate to Oracle9 would then really only
involve modifying things like oratab, environmental variables,
post-wait kernel extenstions giving us much more time for the data
import and resolving any issues and problems that come up.
I forgot to mention that some time ago we performed a similar move
(perhaps naively) with Oracle 7.3.4 binaries and datafiles to a
different production server without incident...so i guess my question
really is if this is an advisable practice on AIX especially with
Oracle9?
I have been going through the backup and recovery manuals as well as
Oracle9's AIX specific documentation and haven't had luck finding
specifics on backup and bare metal recovery of binaries other than
using installation media.
We are doing some sandbox testing to see if we can get it to work but
by no means decided if we will use it even if it does seem to be ok.
Again any information or experience appreciated...thanks.
"Jeff W" <je...@hiddenemailaddress.com> wrote in message news:<3f0dcfba@shknews01>...
dias
Installing 9i in the server runing Oracle7 should not be a problem,
once you have checked all the 9i requirements.
Of course, backup Oracle7 db and binary.
Dias
ia...@shaw.ca (Ian) wrote in message news:<23b28adc.03071...@posting.google.com>...
Lane Lesperance
test server, and then installed into production by copying and
relinking. This WAS sanctioned by Oracle and I have included the Tar
that I opened with metalink about this issue. Hope this helps.
---- Tar text follows ---
Abstract
[06-03]INSTALL IN PRODUCTION BY COPYING ORACLE_HOME FROM TEST ??
Resolution History
12-MAY-03 14:20:13 GMT
### Problem Description: ###
I am upgrading from 7.3.4 on AIX 4.3.3 (32 bit) to 8.1.7. I am
installing and
testing on a computer called TSTSVR which is a system used for
testing. After
the install and migration I will be installing patchset 8.1.7.4 and
the patch
set for security fixes 48-51. If I run rootpre.sh on our production
machine
PRDSVR to install the post wait kernel extension, can I then copy the
ORACLE_HOME from TSTSVR (test) to PRDSVR (prod) to install the fully
patched
software, or do I need to run a full install process and apply the
patches?
12-MAY-03 16:06:29 GMT
UPDATE
=======
Lane,
EXPLANATION
============
Yes, you can copy your Oracle Home from your Test Unix box to your
Production Unix box, but you must to relink it
ACTION PLAN
===========
1) After copy your Oracle Software, please relink it:
Example:
$ORACLE_HOME/bin/relink all > $HOME/relink.out 2> $HOME/relink.out
Thank You!
STATUS
=======
@SCL
13-MAY-03 19:57:04 GMT
New info : Will I also need to run the root.sh script from the test
computer
(TSTSVR) on the production computer (PRDSVR)?
13-MAY-03 20:07:53 GMT
UPDATE
=======
Lane,
EXPLANATION
============
Question 1: Will I also need to run the root.sh script from the test
computer (TSTSVR) on the production computer (PRDSVR)?
Answer 1: Yes, the "root.sh" is necessary to complete the
installation. This file is located under "?/orainst". It creates an
"oratab" file or appends to it if this file already exists with an
entry for the new instance that was created. It also copies some
executables to the local "bin" directory specified by the user in the
installation. This script should be run by "root" after installation.
Thank You!
STATUS
=======
@SCL
15-MAY-03 19:07:05 GMT
New info : Let me summarize where I am.
Environment is 2 AIX servers that are configured nearly identical.
TSTSVR(test)
and PRDSVR(prod).
I am upgrading from 7.3.4 to 8.1.7 using ODMA.
I installed from the CDROM on TSTSVR.
I migrated the database on TSTSVR using ODMA.
I am going to install the 8.1.7.4 patch set and security fixes 48-51
and 54.
I will then complete my testing.
Based on previous info in this tar, to install in prod (PRDSVR):
I will run rootpre.sh from the CDROM on PRDSVR and reboot.
I will copy the directory $ORACLE_HOME from TSTSVR to PRDSVR
I will run $ORACLE_HOME/bin/relink all
I will run $ORACLE_HOME/root.sh as root on PRDSVR
My ORACLE_HOME=/oracle/app/oracle/product/8.1.7
Can you confirm for me that:
I should copy /oracle/app/oracle/product/jre from TSTSVR to PRDSVR
I should copy /oracle/app/oracle/product/oraInventory from TSTSVR to
PRDSVR
I should copy /oracle/app/oracle/product/oui from TSTSVR to PRDSVR
I should copy /etc/oraInst.loc from TSTSVR to PRDSVR
Are there any relinks required for the above copied directories?
Thanks, Lane Lesperance
15-MAY-03 19:30:05 GMT
UPDATE
=======
Lane,
EXPLANATION
============
1) Yes, the above steps are OK, also you can include the /etc/oratab
file.
2) You just need to relink Oracle Server.
3) Also, it is very import to coy the Oracle Inventory and the
oraInst.loc file
If you have additional questions please let me know.
Thank you.
STATUS
=======
@SCL
28-MAY-03 15:30:47 GMT
Country: UNITED STATES
The customer has uploaded the following file via MetaLink:
H:\Oracle\log\relink.out
28-MAY-03 15:32:32 GMT
Country: UNITED STATES
The customer has uploaded the following file via MetaLink:
H:\Oracle\log\relink-errs.out
28-MAY-03 15:33:13 GMT
New info : I did a "relink all" and got some error and warning
messages. I have
uploaded the results of the relink. Are these messages anything that I
need to
be concerned about?
28-MAY-03 16:09:49 GMT
UPDATE
=======
Lane,
Relink.out
==================================================================
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0711-224 WARNING: Duplicate symbol: vppm
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0706-027 The -R /oracle/app/oracle/product/8.1.7/lib/ flag is
ignored.
ld: 0711-224 WARNING: Duplicate symbol: .pw_wait
ld: 0711-224 WARNING: Duplicate symbol: pw_wait
ld: 0711-224 WARNING: Duplicate symbol: .pw_post
ld: 0711-224 WARNING: Duplicate symbol: pw_post
ld: 0711-224 WARNING: Duplicate symbol: .pw_config
ld: 0711-224 WARNING: Duplicate symbol: pw_config
ld: 0711-224 WARNING: Duplicate symbol: .aix_ora_pw_version3_required
ld: 0711-224 WARNING: Duplicate symbol: aix_ora_pw_version3_required
ld: 0711-224 WARNING: Duplicate symbol: ksmsgl_
ld: 0711-224 WARNING: Duplicate symbol: kcbkclx_
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
==================================================================
EXPLANATION
============
Basically there are not errors or fatal errors in your relink.out file
and the above messages (warnings) can be ignored without problem.
If you have additional questions, please let me know.
Thank you.
STATUS
=======
@SCL
28-MAY-03 17:56:26 GMT
Email Update button has been pressed -- Sending email.
12-JUN-03 00:09:30 GMT
TAR passed SCL review date. Setting to HCL.
---- End of Tar text ---
ia...@shaw.ca (Ian) wrote in message news:<23b28adc.03071...@posting.google.com>...
Arjun Choubey
similar then use following sql to generate the command. Edit the
spooled file and add wait after xx number of lines to run the jobs at
a time in background ( depends on server) . This is much much faster
due to block size of 256 K. The default block size is 8k . We tested
with blocks of 8k-1028 but the best result was with 256K . This
scripts starts tar file , transfer the files on another server and
extract the file on another server . Every things happens in parallel
. We use this command on regular basis on Unix to copy the files from
production to development , test , stage etc. and have no issues
set pages 0
set lines 200
spool ssh.ksh
select 'tar cbf 256 - '||file_name||' | ssh oracle@usscora1000
'||' "(cd '||' /; tar xvbpf 256 - )'||'" &'
from dba_data_files
/
spool off
----------------------------------------- output looks like
-------------------------------------------------
#/bin/ksh
set -v
tar cbf 256 - /u20/arjdvdata/XKBD01.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
tar cbf 256 - /u17/arjdvdata/XKBX01.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
tar cbf 256 - /u07/arjdvdata/TEMP07.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
tar cbf 256 - /u07/arjdvdata/TEMP06.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
tar cbf 256 - /u07/arjdvdata/TEMP05.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
wait
tar cbf 256 - /u07/arjdvdata/TEMP04.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
tar cbf 256 - /u07/arjdvdata/TEMP03.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
tar cbf 256 - /u07/arjdvdata/TEMP02.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
tar cbf 256 - /u07/arjdvdata/TEMP01.dbf | ssh oracle@newserver
"(cd /; tar xvbpf 256 - )" &
wait
Charles J. Fisher
> Hi - we need to move a 9.2.0.3 database from one AIX server to
> another. Both servers have similiar hardware and are at the same O/S
> level (AIX4.3.3).
> Does anyone have experience with this approach? Is this method
> supported? And is there any documentation available specifically
> describing the files and directories the rdbms accesses outside of
> $ORACLE_BASE such as the ones in /etc/ and /usr/local/ .
You might try it this way:
1. Transfer everything in your ORACLE_BASE except for:
- datafiles
- control files
- redo logs
- archived logs
2. Using sqlplus, do an O7-style hotbackup; i.e. "alter tablespace x
begin backup;" Copy all the datafiles in this way. You might do an
'alter database backup controlfile to trace;' so you are sure that you
know where everything is.
3. At your window, shut down your database, and transfer a copy of the
control file, a copy of a member of each of the redologs, and all of
the archived logs produced since you first issued you "alter tablespace
begin backup;"
4. On the target machine, do a startup mount and issue a recover database,
then alter database open.
O7-style hot backups seem to be the best approach to me. You might also
consider setting up the secondary as a standby server - your window might
then become (nearly) instantaneous.
---------------------------------------------------------------------------
/ Charles J. Fisher | "Fascism should more properly be called /
/ cfi...@rhadmin.org | corporatism, since it is the merger of state /
/ http://rhadmin.org | and corporate power." -- Mussolini /
---------------------------------------------------------------------------
Sybrand Bakker
<cfi...@rhadmin.org> wrote:
>2. Using sqlplus, do an O7-style hotbackup; i.e. "alter tablespace x
> begin backup;" Copy all the datafiles in this way. You might do an
> 'alter database backup controlfile to trace;' so you are sure that you
> know where everything is.
Just for your info: Oracle does support such a move only when you have
exactly the same Oracle version, to the patch level, and exactly the
same Unix, to the patchlevel. Your advice is unprofessional.
Charles J. Fisher
> >2. Using sqlplus, do an O7-style hotbackup; i.e. "alter tablespace x
> > begin backup;" Copy all the datafiles in this way. You might do an
> > 'alter database backup controlfile to trace;' so you are sure that you
> > know where everything is.
> Just for your info: Oracle does support such a move only when you have
> exactly the same Oracle version, to the patch level, and exactly the
> same Unix, to the patchlevel.
Moving the exact same Oracle release to the exact same OS relase on the
exact same platform is precisely what the original poster was trying to do:
> Hi - we need to move a 9.2.0.3 database from one AIX server to
> another. Both servers have similiar hardware and are at the same O/S
> level (AIX4.3.3).
> Your advice is unprofessional.
As you have obviously not read the original post, I will overlook this
lapse in your normally lucid discussions. Please endeavor to be less
cantankerous; it reflects badly upon our community.
---------------------------------------------------------------------------
/ Charles J. Fisher | "Waste no more time arguing what /
/ cfi...@rhadmin.org | a good man should be. Be one." /
/ http://rhadmin.org | -Marcus Aurelius /
---------------------------------------------------------------------------
Joel Garry
> another. Both servers have similiar hardware and are at the same O/S
> level (AIX4.3.3).
>
> Our change window is short so ideally we would simply like to tarball
> $ORACLE_BASE on Server A and untar on server B.
Check your man tar and be sure you are using a version that handles
links the way you think they should.
Be sure you have exactly the same users and groups (they need to
resolve the same numerically - if you do an ls -l and see numbers
instead of names, you goofed).
Be sure your compilers and paths to access them are exactly the same.
Be sure you understand limitations of SGA and kernel configuration for
what you wind up with.
How similar is similar?
I'm not so sure I understand why the window is important - why not use
the installer before the window?
>
> Does anyone have experience with this approach? Is this method
> supported? And is there any documentation available specifically
> describing the files and directories the rdbms accesses outside of
> $ORACLE_BASE such as the ones in /etc/ and /usr/local/ .
Install Guide, I believe.
jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/fri/business/news_1b18gateway.html
Wizardo
news:23b28adc.03071...@posting.google.com:
> Thanks for all your responses - yes, the 'Server B' destination is a
> production machine. This production server already contains Oracle7
> and we don't feel comfortable firing up the Oracle9 installation
> outside of a change window. Hence why we are looking at other options
> such as restoring the $ORACLE_BASE tarball from Server A into an
> Oracle9 $ORACLE_BASE directory on Server B ( obviously different from
> Oracle7's $ORACLE_BASE). This procedure could be done almost anytime
> as we know those tarball files would not interfere with Oracle7's
> files. The change window to migrate to Oracle9 would then really only
> involve modifying things like oratab, environmental variables,
> post-wait kernel extenstions giving us much more time for the data
> import and resolving any issues and problems that come up.
>
You worry overmuch. As long as you are sure to install the 9i binaries
into a separate ORACLE_HOME, you will not impact your running system.
I STRONGLY advise against going the 'tarball' route. When it does not
work you will have no idea where to start looking for resolution.
And finally, it's simple does not take *that long* to install from the
CD.
> I forgot to mention that some time ago we performed a similar move
> (perhaps naively) with Oracle 7.3.4 binaries and datafiles to a
> different production server without incident...so i guess my question
> really is if this is an advisable practice on AIX especially with
> Oracle9?
>
Well, OK, but it wasn't supported then either. At version 6.0.36 I
did the same thing on a VAX, but since then I have tried similar steps
out of urgency on HP-to-HP and Solaris-to-Solaris transfers and they
were all failed miserably.
> I have been going through the backup and recovery manuals as well as
> Oracle9's AIX specific documentation and haven't had luck finding
> specifics on backup and bare metal recovery of binaries other than
> using installation media.
>
In a bare metal recovery, you're restoring the whole kit and kaboodle
from backup media to a system. The same O/S, the same patches, the
same Oracle, the same *everything*. Here, you're trying to pick and
choose a few pieces and hope that it works.
> We are doing some sandbox testing to see if we can get it to work but
> by no means decided if we will use it even if it does seem to be ok.
> Again any information or experience appreciated...thanks.
>
For what you want to do, *especially* since this will be a production
server, you should install from the media, add patches from the media,
get a good cold backup before you start. This is PRODUCTION. Do it
right the first time and you'll not have to always have a silly thought
in the back of your mind "what did I miss?" when calling Oracle Support.
I really don't mean to rain on your parade. You sound like you have an
urgent need and are looking for shortcuts. However, my experience
tells me this:
1) This is (or will be) Production. Do you want it done right or
with some hack?
2) Oracle seems to have taken a page from Microsoft's install manual.
Not all pertinent files are under $ORACLE_BASE. What will you
miss? How will you know?
3) You CAN install a new rev of Oracle onto your server while it is
running. If you're concerned about impacting the running system,
do it after hours. We're IS - we don't sleep!
4) As my 97-year-old Gramma always says...if you haven't time to do
it right, when will you have time to do it over?
Good Luck
Mike
Sybrand Bakker
<wwiizza...@aattttbbii.com> wrote:
>4) As my 97-year-old Gramma always says...if you haven't time to do
> it right, when will you have time to do it over?
Everyone needs to have that one painted in a list on their wall in
their office.