Re: Moving 10g from server to server.

On 11 May 2007 23:13:01 -0700, Joe <joe1977_at_tlen.pl> wrote:

>On May 12, 1:17 am, sybra..._at_hccnet.nl wrote:
>> Comments embedded
>>
>> RMAN is used for *physical* backup.
>
>so, which tool you would use to do migration from one serve to the
>another?
>
>
>> Evidently, you will end up with
>> the *same* datafiles, which may be on a different *location* depending
>> on the *set newname* commands you feed it, prior to the actual restore
>> command
>
>is it good or bad? is it efficient, once a one is moving a database
>from one pc to the another (abviously this new i more powerful with
>more memory, etc)
>should I move the databse with RMAN, or rather create a new instance
>of the same database on the new server, create tablespaces on the new
>hard disk drives, assign more space for archivelog, etc, and then
>execute imp form expdmp previously taken?
>What is your opinion?
>
>
>
>> >Question: what would be the most efficient way to move database
>> >instance from one server the another knowing that disk allocations for
>> >tablespaces, archivelogs, etc will be changes.
>>
>> It depends. If you are going to relocate data to different tablespaces
>> or going to reduce or increase the # of datafiles ,
>
>nope. the same tablespaces (however located on different drives like
>D: instead of C:) I am thinking about keeping thew same # of
>datafiles.
>
>
>> export import, as
>> RMAN is used for *physical* backup and restore. Please study the
>> impact of the word *physical*.
>
>I am reading Osborne's Oracle Database 10g - The Complete Reference,
>but did not get to that part yet. unfortunately.
>
>
>
>> They will imoact database operation as in a normal situation.
>? normal situation?
>
>
>
>Sybrand, thank you for your respone.
>

Your reply calls for the proverbial crystal ball. I don't know anything about your database, nor about the new server, so how would I be capable of an adequate advice.
Theoretically with the same platform, one could 'clone' the database, ie
create a new instance (making sure init.ora is correct) run 'alter database backup controlfile to trace' on the source server. adapt the resulting trace file, copy it over, copy the datafiles etc, start the new instance with nomount, and run the trace file as a sql scriot, to create a controlfile,
In 9i one would probably create a new instance, and use rman to run the duplicate database command, and sit back and drink coffee. In 10g that is probably even easier using grid control. One could hit a button, go to the rest room, go outside to smoke a cigarette, or whatever, and come back and notice your work has been done. I would likely use RMAN's duplicate database command. If the database would need 'reorganization' I would use exp/imp. Whether disk allocations change is unimportant, as long as the current files fit.

For rman duplicate database the source database doesn't need to go down, for the 'clone' operation it does.

-- 
Sybrand Bakker
Senior Oracle DBA