RE: 8174 32 bit to 9204 64 big
- From: "Hodgkinson, Stephen" <Stephen.Hodgkinson@xxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 2 Apr 2004 22:44:27 +1000
I thought the same as Thomas Biju - oracle takes care of the 32-64 bit
conversion
for you, when you do the upgrade and the DBA has no additional tasks to do.
Please let me known if you disagree as I will be upgrading production in a
few weeks.
Stephen
-----Original Message-----
From: Thomas Biju [mailto:BThomas@xxxxxxxxxx]
Sent: Friday, 2 April 2004 8:13
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: 8174 32 bit to 9204 64 big
>>>Install 8174 (64 bit) software
>>>Convert the db from 32 bit to 64 (8174)
>>>migrate the db from 8174 (64 bit) to 9204 (64 bit).
Srinivas,
I do not think you need to perform the 64 bit conversion step at all. Oracl=
e does the word size conversion during the upgrade implicitly.=20
I have done such upgrade using the DBUA and using scripts without any issue=
s...
B.
-----Original Message-----
From: DENNIS WILLIAMS [mailto:DWILLIAMS@xxxxxxxxxxxxx]
Sent: Thursday, April 01, 2004 3:46 PM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: 8174 32 bit to 9204 64 big
Srinivas
My theory as a DBA is to perform tasks in a manner that is least likely
to cause bad consequences. Is there any way export/import would work for
you? I have a much warmer feeling about using that to relocate my important
data. Just create a new 9i database, check it out, make sure it is ready to
go, practice the export/import, then perform the cutover. Much less to go
wrong.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx=20
___________________________________________________________________________=
__________________________________
This electronic transmission and any attached files are intended solely for=
the person or entity to which they are addressed and may contain informati=
on that is privileged, confidential or otherwise protected from disclosure.=
Any review, retransmission, dissemination or other use, including taking a=
ny action concerning this information by anyone other than the named recipi=
ent, is strictly prohibited. If you are not the intended recipient or have =
received this communication in error, please immediately notify the sender =
and destroy this communication.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
************** IMPORTANT MESSAGE **************
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. If you are not the intended recipient
please advise the sender by return email, do not use or disclose the contents,
and delete the message and any attachments from your system. Unless
specifically indicated, this email does not constitute formal advice or
commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123
124) or its subsidiaries.
**************************************************
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
