Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 679 invoked from network); 9 Sep 2006 16:08:30 -0500 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 9 Sep 2006 16:08:30 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C1A7540AE50; Sat, 9 Sep 2006 17:08:04 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31796-03; Sat, 9 Sep 2006 17:08:04 -0400 (EDT) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3E71640AE57; Sat, 9 Sep 2006 17:08:04 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Sat, 09 Sep 2006 17:07:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 99D7A40AE1C for ; Sat, 9 Sep 2006 17:07:01 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31547-10 for ; Sat, 9 Sep 2006 17:07:01 -0400 (EDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C928940AE57 for ; Sat, 9 Sep 2006 17:07:00 -0400 (EDT) Received: by nf-out-0910.google.com with SMTP id p46so1151783nfa for ; Sat, 09 Sep 2006 14:07:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mx5sAMzSJIgIvnPraI9HYl/K9pcuBY/a5Xywolse5RkR3ELHmHnwfDgG8LJwFIukrglvbY33phiKRMelDHTrmXMhDySuif2N04yt8xUu42e7BxIX14RpEfJqzSjT0l3ONsDX4lOZgXn+yvG9Q+Aw+ycRIlzw/pjqLa6ro1LzmbQ= Received: by 10.49.19.18 with SMTP id w18mr5959796nfi; Sat, 09 Sep 2006 14:07:23 -0700 (PDT) Received: by 10.49.12.11 with HTTP; Sat, 9 Sep 2006 14:07:23 -0700 (PDT) Message-ID: <6d0a3ba80609091407w68cde23ra28cbf398639bc81@mail.gmail.com> Date: Sat, 9 Sep 2006 23:07:23 +0200 From: "goran bogdanovic" To: jkstill@gmail.com Subject: Re: Restoring 64 bit database to 32 bit Server Cc: "Oracle-L Freelists" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_216449_17445065.1157836043205" References: X-archive-position: 39219 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: goran00@gmail.com Precedence: normal Reply-to: goran00@gmail.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at avenirtech.net ------=_Part_216449_17445065.1157836043205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jared, I think Dimitre made a good point in his post. I would just add that in your case including the trace backup of control file together with rman controlfile autobackup backup could help. Cheers, Goran On 9/8/06, Jared Still wrote: > > > Servers: > Source server: 64 bit RedHat ES 4 > Target server : 32 bit RedHat ES4 > > Oracle: 9.2.0.7 - 64 bit on the 64 bit server - 32 bit on the 32 bit > server. > > What I am trying to do is restore an Oracle database from 64 bit server to > a 32 bit server. > > The assumption is that the source database is 64 bit, it has died, and > took its storage with it. > > The database has been backed up with RMAN, there is no RMAN repository, > and autobackup of controlfiles is turned on. > > The only server available to do a restore is a 32 bit RH server. > > The database files for 32 bit and 64 bit Oracle are the same. > The PL/SQL must be recompiled, but that has nothing to do with restoring > the database. > > The control files are however, different - they must be recreated when > migrating from 32-bit -> 64 bit. > ( see > http://download-west.oracle.com/docs/cd/B19306_01/relnotes.102/b15666/toc.htm#CHDGAJDG > ) > > This is making it somewhat difficult to restore the database. > > The controlfile can easily be restored to the 64 bit server, but not the > 32 bit server. > Following are the results of attempting to do so: > > SQL> get restore_0905_ctlfile.sql > 1 -- This procedure will restore the control file as text > 2 declare > 3 devtype varchar2(256); > 4 done boolean; > 5 begin > 6 devtype := dbms_backup_restore.deviceallocate(type=>'sbt_tape'); > 7 dbms_backup_restore.restoresetdatafile; > 8 > dbms_backup_restore.restorespfileto('/u01/app/oracle/product/9.2.0/9ir2dev/dbs/spfilets01.ora'); > > 9 dbms_backup_restore.restorebackuppiece('c-2182868868-20060905-01', > DONE=>done); > 10 dbms_backup_restore.devicedeallocate; > 11* end; > 12 / > -- This procedure will restore the control file as text > * > ERROR at line 1: > ORA-19624: operation failed, retry possible > ORA-19507: failed to retrieve sequential file, > handle="c-2182868868-20060905-01", parms="" > ORA-27029: skgfrtrv: sbtrestore returned error > ORA-19511: Error received from media manager layer, error text: > Backup file not found in NetBackup catalog > ORA-07202: sltln: invalid parameter to sltln. > ORA-06512: at "SYS.X$DBMS_BACKUP_RESTORE ", line 1371 > ORA-06512: at line 9 > > The file does exist, as I restored it to a 64 bit server. > > The problem is that the datafiles cannot be restored without the > controlfile. > A new controlfile cannot be created without the datafiles. > > An interesting catch-22, no? > > At this point, I am ready to try building a database with the identical > datafiles, and then attempt the restore over the new files. > ( I know what the datafiles are due to job that runs periodically that > backs up the controfile > to trace - I restored the file manually from backups via NetBackup) > > Any thoughts on another way to do this restore? > > Thanks, > > Jared Still > Certifiable Oracle DBA and Part Time Perl Evangelist > ------=_Part_216449_17445065.1157836043205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jared,

I think Dimitre made a good point in his post. I would just add that in your case including the trace backup of control file together with rman controlfile autobackup backup could help.


Cheers,

Goran


On 9/8/06, Jared Still <jkstill@gmail.com> wrote:

Servers:
  Source server:  64 bit RedHat ES 4
  Target server :  32 bit RedHat ES4

Oracle: 9.2.0.7 - 64 bit on the 64 bit server - 32 bit on the 32 bit server.

What I am trying to do is restore an Oracle database from 64 bit server to a 32 bit server.

The assumption is that the source database is 64 bit, it has died, and took its storage with it. 

The database has been backed up with RMAN, there is no RMAN repository,
and autobackup of controlfiles is turned on.

The only server available to do a restore is a 32 bit RH server.

The database files for 32 bit and 64 bit Oracle are the same.
The PL/SQL must be recompiled, but that has nothing to do with restoring the database.

The control files are however, different - they must be recreated when
migrating from 32-bit -> 64 bit.
( see http://download-west.oracle.com/docs/cd/B19306_01/relnotes.102/b15666/toc.htm#CHDGAJDG)

This is making it somewhat difficult to restore the database.

The controlfile can easily be restored to the 64 bit server, but not the 32 bit server.
Following are the results of attempting to do so:

SQL> get restore_0905_ctlfile.sql
  1  -- This procedure will restore the control file as text
  2  declare
  3     devtype varchar2(256);
  4     done boolean;
  5  begin
  6     devtype := dbms_backup_restore.deviceallocate(type=>'sbt_tape');
  7     dbms_backup_restore.restoresetdatafile;
  8     dbms_backup_restore.restorespfileto('/u01/app/oracle/product/9.2.0/9ir2dev/dbs/spfilets01.ora');
  9     dbms_backup_restore.restorebackuppiece('c-2182868868-20060905-01', DONE=>done);
 10     dbms_backup_restore.devicedeallocate;
 11* end;
 12  /
-- This procedure will restore the control file as text
*
ERROR at line 1:
ORA-19624: operation failed, retry possible
ORA-19507: failed to retrieve sequential file,
handle="c-2182868868-20060905-01", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
Backup file <c-2182868868-20060905-01> not found in NetBackup catalog
ORA-07202: sltln: invalid parameter to sltln.
ORA-06512: at "SYS.X$DBMS_BACKUP_RESTORE ", line 1371
ORA-06512: at line 9

The file does exist, as I restored it to a 64 bit server.

The problem is that the datafiles cannot be restored without the controlfile.
A new controlfile cannot be created without the datafiles.

An interesting catch-22, no?

At this point, I am ready to try building a database with the identical datafiles, and then attempt the restore over the new files.
( I know what the datafiles are due to job that runs periodically that backs up the controfile
  to trace - I restored the file manually from backups via NetBackup)

Any thoughts on another way to do this restore?

Thanks,

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

------=_Part_216449_17445065.1157836043205-- -- http://www.freelists.org/webpage/oracle-l