[prev in list] [next in list] [prev in thread] [next in thread]
List: suse-oracle
Subject: Re: AW: [suse-oracle] RMAN - Recovery Question
From: Arno Seidel <a.seidel () ehotel ! ag>
Date: 2007-04-26 15:40:37
Message-ID: 4630C7F5.10108 () ehotel ! ag
[Download RAW message or body]
Hi list,
with the great help of Mathias Zarick, i found the problem ... and a
solution for it.
The Problem is/was that one tablespace contains a offline databasefile
(which is offline since 2 Years).
when trying to recover that tablespace rman searches for the last
redolog which contains the last SCN of that
databasefile. And i don ´t have any archived-log which is older than 4 weeks.
after running that command:
rman>recover database until logseq 2725 skip tablespace users;
recovered the whole database without the specified tablespace ...
and on the sqlplus prompt i issued following commands:
sqlplus> alter database datafile 7,9,15,11,12,13,14,16 offline for drop;
(all datafiles in the tablespace users)
and finaly i could issue:
splplus> alter database open resetlogs;
so i ´ve now to find the best solution to cleanup my database / to delete
the offline datafile which is
(how could it be diffrent) the first datafile of the talbespace users ...
and the database runs in compatible=10.1.0.2.0
cheers
Arno
Wolfgang Seymann schrieb:
> Hi
> Before restoring the database you should set an "until clause", which then
> is valid for the restore and the recovery, but only if you include all
> statements in the brackets of a run command.
>
>
>
> run{
> set until sequence 2725;
> restore database;
> recover database;
> alter database open resetlogs;
> }
>
>
> If I understood your backupscript you are moving your backups to another
> destination every day, this is why they are considered expired by rman,
> expired meaning that they are not available at the destination where rman
> has put them.
>
> If you have deleted expired backups they are deleted from the controlfile
> and or the rman catalog. If so, rman does not know of any backups of these
> archived redologs it would require to successfully recover your database.
>
> Regards and maybe this helps
> Wolfgang
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Arno Seidel [mailto:a.seidel@ehotel.ag]
>> Gesendet: Donnerstag, 26. April 2007 11:42
>> An: Mathias Zarick
>> Cc: suse-oracle@suse.com
>> Betreff: Re: [suse-oracle] RMAN - Recovery Question
>>
>> Hi there,
>>
>> ok i did so .. and got to the same error.
>> restore database from TAG 'TAG20070421T030115'; (This is the "newest"
>> full backup)
>> recover database until sequence 2725 ; ( this is the newest sequence
>> (INCREMENTAL-2007-04-25)
>> and then i get:
>> starting media recovery
>>
>> Oracle Error:
>> ORA-01547: Warnung: RECOVER erfolgreich, doch OPEN RESETLOGS wurde
>> folgenden Fehler ergeben
>> ORA-01152: Backup-Datei zum Wiederherstellen der Datei 1 war nicht alt
>> genug
>> ORA-01110: Datendatei 1: '/opt/oracle/oradata/LNCL/system01.dbf'
>>
>> RMAN-00571: ===========================================================
>> RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
>> RMAN-00571: ===========================================================
>> RMAN-03002: failure of recover command at 04/26/2007 11:36:33
>> RMAN-06053: unable to perform media recovery because of missing log
>> RMAN-06025: no backup of log thread 1 seq 2628 lowscn 170743717 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2627 lowscn 170697395 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2626 lowscn 170686962 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2625 lowscn 170630529 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2624 lowscn 170565582 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2623 lowscn 170558006 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2622 lowscn 170493998 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2621 lowscn 170493135 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2620 lowscn 170477003 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2619 lowscn 170428082 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2618 lowscn 170378019 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2617 lowscn 170333403 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2616 lowscn 170325986 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2615 lowscn 170247625 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2614 lowscn 170247144 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2613 lowscn 170183017 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2612 lowscn 170114393 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2611 lowscn 170106096 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2610 lowscn 170001426 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2609 lowscn 170001105 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2608 lowscn 169980094 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2607 lowscn 169919339 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2606 lowscn 169854880 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2605 lowscn 169841017 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2604 lowscn 169732868 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2603 lowscn 169732341 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2602 lowscn 169720299 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2601 lowscn 169646137 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2600 lowscn 169598026 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2599 lowscn 169572066 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2598 lowscn 169452989 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2597 lowscn 169452696 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2596 lowscn 169420850 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2595 lowscn 169329557 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2594 lowscn 169314780 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2593 lowscn 169264674 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2592 lowscn 169166798 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2591 lowscn 169166524 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2590 lowscn 169155941 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2589 lowscn 169084934 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2588 lowscn 169053889 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2587 lowscn 169032181 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2586 lowscn 168938023 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2585 lowscn 168903688 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2584 lowscn 168884121 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2583 lowscn 168821058 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2582 lowscn 168819908 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2581 lowscn 168760136 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2580 lowscn 168705795 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2579 lowscn 168686469 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2578 lowscn 168584537 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2577 lowscn 168584065 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2576 lowscn 168542226 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2575 lowscn 168504705 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2574 lowscn 168468843 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2573 lowscn 168462713 found to
>> restore
>> RMAN-06025: no backup of log thread 1 seq 2572 lowscn 168440797 found to
>> restore
>> MAN-06025: no backup of log thread
>>
>>
>> Mathias Zarick schrieb:
>>
>>> Hi Arno,
>>>
>>> when you restore a controlfile you are in an incomplete recovery case.
>>>
>> (backup controlfile)
>>
>>> The "recover database" command signals that you start a complete
>>> recover.., which is only possible, when you have the latest contolfile.
>>>
>>> You have to yo use "recover database until ...";
>>> Also you can work with a "SET UNTIL SEQUENCE <...> THREAD 1;"
>>> within the run block.
>>>
>>> afterwards open with resetlogs.
>>>
>>> Regards Mathias
>>>
>>>
>>> -----Original Message-----
>>> From: Arno Seidel [mailto:a.seidel@ehotel.ag]
>>> Sent: Thursday, April 26, 2007 9:02 AM
>>> To: suse-oracle@suse.com
>>> Subject: Re: [suse-oracle] RMAN - Recovery Question
>>>
>>> Ronny Egner schrieb:
>>>
>>>
>>>> Arno Seidel schrieb:
>>>>
>>>>
>>>>> Maxim Tkachenko schrieb:
>>>>>
>>>>>
>>>>>>> recover database;
>>>>>>> rman stops after some time and says:
>>>>>>> RMAN-06025: no backup of log thread 1 seq found to restore
>>>>>>> several times ... these requested log sequences are older than 3
>>>>>>> weeks and i don?t have them any more.
>>>>>>> Why does Rman want this old logs???
>>>>>>> And how can i recover the database without these old logs?
>>>>>>>
>>>>>>> any help would be great.
>>>>>>>
>>>>>>> regards from germany
>>>>>>>
>>>>>>> Arno Seidel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> use "restore archivelog time " or "restore archivelog sequence XXXX".
>>>>>> Number of sequence may give from backup.log or use "list backup"
>>>>>> on rman.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> list backup only shows the highest missing archived_log sequwnce and
>>>>> these backupsets are marked as
>>>>> expired (they are over 3 weeks old and happend before 3 full backups
>>>>> of the database).
>>>>>
>>>>> There must be a way to tell rman to skip these verry old
>>>>>
>> archived_logs.
>>
>>>>> crosscheck backup
>>>>> and delete expired backup does not change the behavior of the recover
>>>>> command ...
>>>>>
>>>>>
>>>> I ´m sorry but this behavior is completely anormal. I ´ve never
>>>> seen that before.
>>>> Could you show the complete script please and the complete output?
>>>>
>>>>
>>>>
>>>>
>>> This is the script for the backup. from monday til friday it runs
>>> (rman.sh day) and on saturday
>>> it runs (rman.sh week)
>>>
>>> #!/bin/bash
>>>
>>> DATE=`date '+%Y-%m-%d'`
>>> export ORACLE_HOME=/opt/oracle/product/R2
>>> export NLS_LANG=German_Germany.utf8
>>> RMAN_BIN="/opt/oracle/product/R2/bin/rman"
>>>
>>> DBUSR="XXXX"
>>> DBPWD="XXXXXX"
>>> DBSID="LNCL"
>>>
>>> function DAY {
>>> $RMAN_BIN TARGET $DBUSR/$DBPWD@$DBSID NOCATALOG <<EOF
>>> backup as compressed backupset incremental level = 1 database plus
>>> archivelog delete input tag ='INCREMENTAL-$DATE';
>>> EOF
>>> }
>>>
>>> function WEEK {
>>> $RMAN_BIN TARGET $DBUSR/$DBPWD@$DBSID NOCATALOG <<EOF
>>> backup as compressed backupset incremental level = 0 database noexclude
>>> plus archivelog delete input tag ='Full-$DATE';
>>> EOF
>>> }
>>>
>>> function CONFIGURE {
>>> #mkdir /opt/rmanbackup
>>> #chown oracle:oinstall /opt/rmanbackup
>>> $RMAN_BIN TARGET $DBUSR/$DBPWD@$DBSID NOCATALOG <<EOF
>>> configure channel device type disk format
>>> '/opt/rmanbackup/rman_%t_%s_%p.dbf';
>>> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
>>> CONFIGURE CONTROLFILE AUTOBACKUP ON;
>>> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
>>> '/opt/rmanbackup/%F';
>>> EOF
>>> }
>>>
>>> function CLEAN {
>>> $RMAN_BIN TARGET $DBUSR/$DBPWD@$DBSID NOCATALOG <<EOF
>>> report obsolete;
>>> delete noprompt obsolete;
>>> EOF
>>> }
>>>
>>> function MOVE {
>>> mount /opt/EXT_rmanbackup
>>> mv /opt/rmanbackup/* /opt/EXT_rmanbackup/
>>> umount /opt/EXT_rmanbackup
>>> }
>>>
>>> case "$1" in
>>> day)
>>> DAY
>>> MOVE
>>> ;;
>>>
>>> week)
>>> WEEK
>>> MOVE
>>> ;;
>>> configure)
>>> CONFIGURE
>>> ;;
>>> *)
>>> echo "USAGE $0 week / day"
>>> ;;
>>> esac
>>>
>>> To recover i did following steps:
>>> 1. setup a new server (SLES 9)
>>> 2. installed the same Oracle Release 10g R2
>>> 3. copied the rman backupfiles to the same desitination on the new host
>>> 4. startet rman target / nocatalog
>>> and issued following commands:
>>>
>>> SET DBID 2353143907
>>> STARTUP FORCE NOMOUNT PFILE='/opt/oracle/product/R2/dbs/initLNCL.ora';
>>> run {
>>> SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
>>> '/opt/rmanbackup/%F';
>>> restore controlfile from autobackup maxdays 2;
>>> }
>>> shutdown immediate;
>>> startup mount;
>>> restore database;
>>>
>>> every thing runs fine, and this is the output:
>>>
>>>
>>> executing command: SET CONTROLFILE AUTOBACKUP FORMAT
>>>
>>> Starting restore at 26-APR-07
>>> using channel ORA_DISK_1
>>>
>>> channel ORA_DISK_1: looking for autobackup on day: 20070426
>>> channel ORA_DISK_1: looking for autobackup on day: 20070425
>>> channel ORA_DISK_1: autobackup found:
>>> /opt/rmanbackup/c-2353143907-20070425-00
>>> channel ORA_DISK_1: control file restore from autobackup complete
>>> output filename=/opt/oracle/oradata/LNCL/control01.ctl
>>> output filename=/opt/oracle/oradata/LNCL/control02.ctl
>>> output filename=/opt/oracle/oradata/LNCL/control03.ctl
>>> Finished restore at 26-APR-07
>>> RMAN> SPOOL LOG TO '/tmp/backup.log'
>>> RMAN> restore database;
>>> RMAN>recover database;
>>> RMAN>list backup;
>>>
>>> and look at attached backup.log
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> To unsubscribe, email: suse-oracle-unsubscribe@suse.com
>> For additional commands, email: suse-oracle-help@suse.com
>> Please see http://www.suse.com/oracle/ before posting
>>
>
>
>
>
--
To unsubscribe, email: suse-oracle-unsubscribe@suse.com
For additional commands, email: suse-oracle-help@suse.com
Please see http://www.suse.com/oracle/ before posting
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic