RECOVER DATABASE question again.
Denny Koovakattu
You will not be able to recover using a backup taken while the
database was active without putting the tablespace in backup mode.
Though not supported, if there was no activity on the production
database while you were taking the backup, you should be able to
recover. ( I wouldn't bet on it. ) I would suggest taking a proper
backup and then try to recover using that.
Regards,
Denny
In article <378a5...@ns.mosbb.com>,
"Alexander Chupin" <chu...@mail.mosbb.com> wrote:
> Good day,
>
> We have database in archivelog mode.
> Every weekend, when nobody work, our
> operators copy database, redolog and
> control fies to another server using
> xcopy.exe command, without shutdown
> server or other preparation for this
> action (as alter tablespace xxx begin
> backup,etc.).
> Because it strategy of backup was
> developed not by me, I'm interested
> how I can to recover this instance
> on the second server?
> Now I tried the following.
>
> startup mount exclusive;
> alter database recover database until cancel using backup controlfile;
>
> I received in trace file:
>
> ---------- begin of trace file --------------
> Mon Jul 12 11:54:41 1999 -
> alter database recover database until cancel using backup
controlfile
> Mon Jul 12 11:54:41 1999 - Media Recovery Start
> WARNING! Recovering data file 1 from a fuzzy file. If not the
current
> file
> it might be an online backup taken without entering the begin backup
> command.
> WARNING! Recovering data file 2 from a fuzzy file. If not the
current
> file
> it might be an online backup taken without entering the begin backup
> command.
> WARNING! Recovering data file 3 from a fuzzy file. If not the
current
> file
> [...]
> WARNING! Recovering data file 36 from a fuzzy file. If not the
> current file
> it might be an online backup taken without entering the begin backup
> command.
> Media Recovery Log
> ORA-279 signalled during: alter database recover database until
> cancel using...
> Mon Jul 12 12:31:06 1999 -
> alter database recover database until cancel using backup
controlfile
> Mon Jul 12 12:31:06 1999 -
> Media Recovery Start
> ORA-275 signalled during: alter database recover database until
> cancel using...
> Mon Jul 12 12:32:10 1999 -
> alter database recover cancel
> Mon Jul 12 12:32:10 1999 -
> Incomplete recovery done UNTIL CHANGE 1099617362232
> Media Recovery Cancelled
> Completed: alter database recover cancel
> ---------- end of trace file --------------
>
> Production database now is operating Ok, while.
> Can anybody tell me, what I must to do to recover
> second database using archivelog file from
> production database.
> Is it available? Or I must send all files from second
> server to nul.
>
> Thank you in advance.
> WBR, Alexander.
--
Denny Koovakattu
de...@vitalsol.com
http://vitalsol.com/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
tmgn
seem to know that the Tablespaces have to be in Backup mode when copying
the Datafiles and yet you didnt do it !!!
It is perfectly logical that ORacle called it as a Fuzzy Backup !!
Why dont U try the Proper Way( include Begin & End Backup modes) and then
Copy the Datafiles,Archived Redo log files to the 2nd node.
Also do a
svrmgr>Alter database backup controlfile to trace;
on the 1st Database
and copy this file over to the 2nd Host,Edit it to reflect the new file
locations and
Recreate the Database using
>Startup nomount;
>Create Controlfile set database "DB_2 " RESETLOGS ....;
will create New Controlfile,Redolog files and the Database using the Copied
Datafiles.
>Recover database using backup controlfile until Cancel;
will recover the Database by applying the Archived redolog files;
>Alter database open resetlogs;
This procedure works fine ..
-Thiru
Connor McDonald
You have two options:
hot backup -
you MUST perform alter tablespace ??? begin backup and end backup for
each tablespace whose files you copy
cold backup -
shut the database down and copy the files
Anything else could leave you in a lot of bother
Cheers
--
===========================================
Connor McDonald
"These views mine, no-one elses etc etc"
connor_...@yahoo.com
"Some days you're the pigeon, and some days you're the statue."
Alexander Chupin
Alexander Chupin
tmgn wrote in message <378A51E6...@excite.com>...
>Why dont U try the Proper Way( include Begin & End Backup modes) and then
As I mentioned above, this strategy was developed not by me.
I can only assume that this DBA, which developed this strategy,
afraided some incidents which can occured during ONLINE
BACKUP of 25 Gb tablespace.
By the way, what realy can occur during this procedure?
Alexander Chupin
Thanx to all, who answered. As I assumed this
technology of backup is not unerstandable and bad.
Denny Koovakattu wrote in message <7mdmlk$voa$1...@nnrp1.deja.com>...
>Though not supported, if there was no activity on the production
>database while you were taking the backup, you should be able to
>recover. ( I wouldn't bet on it. )
Now I made some experiment with a little database.
1. startup database
2. create table.
3. insert into table 6000 rows.
4. disconnect from database.
5. save database files, redolog files, ctrlfile.
6. connect to database
7. update 6000 rows.
8. disconnect from database
9. connect internal
10. shutdown abort
11. restore database file, redolo files, ctrlfile
Now I'd like roll forward using archive log files.
12. startup mount exclusive
11. alter database recover database until cancel using backup controlfile;
received:
*
ORA-00279: change 53109 generated at 07/13/99 15:48:09 needed for thread 1
ORA-00289: suggestion : /dsk1/arcs/AR0000000138.0001
ORA-00280: change 53109 for thread 1 is in sequence #138
When I tried issue: alter database recover cancel;
I'm receiving:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error
below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/dev/vx/rdsk/rLNX.system'
After this database already coldn't be started.
>startup
ORACLE instance shut down.
ORACLE instance started.
Total System Global Area 4754704 bytes
Fixed Size 48400 bytes
Variable Size 4222976 bytes
Database Buffers 409600 bytes
Redo Buffers 73728 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
>alter database open resetlogs
*
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/dev/vx/rdsk/rLNX.system'
--------------------------------------------
The end of outrage.
If I don't tired you. I wold like to receive any
advices to change any steps in this
experiment for obtaining more
successul result.
Thanx in advance,
WBR, Alexander.
tmgn
running are HOT backups and Export Backups(in Consistent Mode) .
What do U mean by Saving datafiles as U mentioned in Step 5.
What happens when U put a Tablespace in Backup mode is that the associated
Datafile headers are frozen to reflect the CheckPoint SCN .But the
Updates/Inserts to the Segments are not blocked. They are stored in the Redolog
files which may be used to Recover the Database in case of a Crash.
Since the Datafiles are Consistent now, an OS Level Backup is Valid and can be
used for subsequent Recoveries.
When you End the Tablespace Backup mode, the Datafile & Control file headers
are updated with the present SCN and becomes insync with the rest of the
Database.
In case of a Crash when the hotbackup is going on,
>Alter database datafile ' ......' end backup;
will make it Consistent without applying any Redolog files.
So U dont need to worry about putting a 25GB Tablespace in Hotbackup mode as
feared by U'r predecessor.
In U'r Case, Since the files are from a 'Fuzzy' backup , Oracle complains that
even the SYSTEM file has to be recovered.
Try Recovering from a Cold backup or a Valid Hotbackup or a Consistent Export
Backup...
-Thiru
Vadim Grepan
Alexander Chupin пишет в сообщении <378b3...@ns.mosbb.com> ...
>Hi,
>
>Thanx to all, who answered. As I assumed this
>technology of backup is not unerstandable and bad.
>
If your database in ARCHIVELOG, only full cold backup or ALTER command
availble. It's follow from documentation. sic
Denny Koovakattu
1. Do not backup your online redo log files. Even if you do back them
up, do not restore them.
2. If your database is running in archive log mode, then you can take
either offline/cold or online/hot backups. Else you can only take
offline/cold backups.
a. While taking offline backups, do a shutdown normal. Do not backup
the files after doing a shutdown abort.
b. If you are taking online backups, put each tablespace into backup
mode, copy the datafiles to the backup location and then take the
tablespace out of backup mode. If your database crashes during online
backup, for versions prior to 7.3 ( I did not check with 7.2 ), you may
have to do crash recovery. For versions 7.3+, you can use the 'alter
database datafile <name> end backup' for all the datafiles for the
tablespace in backup mode to take the tablespace out of backup mode.
Another point to consider is the increased redo generation during online
backups. For a tablespace in backup mode, the first time a block is
modified, the entire block is written to the redo log. All later changes
till the block is flushed to disk generate only normal redo. The next
change after the block is flushed to disk also writes the entire block
to the redo log.
Taking backups is quite straight forward and easy. In your test case I
don't believe you put the tablespace in backup mode. If you want to
avoid this then shutdown the database before taking the backup. Also you
restored the online redo log files. Don't do that. Always use the
current redo log files.
Regards,
Denny
In article <378b3...@ns.mosbb.com>,
"Alexander Chupin" <chu...@mail.mosbb.com> wrote:
> Hi,
>
> Thanx to all, who answered. As I assumed this
> technology of backup is not unerstandable and bad.
>
Paul da Cruz
recording the occurrence of checkpoints in the headers of the online
datafiles being backed up as a direct result of issuing the ALTER
TABLESPACE BEGIN BACKUP statement.
When a datafile is restored, it has "knowledge" of the most recent
datafile checkpoint that occurred before the online tablespace backup,
not any that occurred during it. As a result, Oracle asks for the
appropriate set of redo log files to apply should recovery be needed.
After the datafile copy is completed, Oracle advances the file header to
the current database checkpoint. This is done after the ALTER TABLESPACE
END BACKUP statement is executed. In your case the datafile is now
inconsistent, but the checkpoint info in the header file can also result
in overlapping data from the redo log files that are applied during
recovery.
Paul da Cruz
Connor McDonald wrote:
>
> Alexander Chupin wrote:
> >
> > Good day,
> >
> > We have database in archivelog mode.
> > Every weekend, when nobody work, our
> > operators copy database, redolog and
> > control fies to another server using
> > xcopy.exe command, without shutdown
> > server or other preparation for this
> > action (as alter tablespace xxx begin
> > backup,etc.).
> > Because it strategy of backup was
> > developed not by me, I'm interested
> > how I can to recover this instance
> > on the second server?
> > Now I tried the following.
> >
> > startup mount exclusive;
> > alter database recover database until cancel using backup controlfile;
> >
> > I received in trace file:
> >
> > ---------- begin of trace file --------------
> > Mon Jul 12 11:54:41 1999 -
> > alter database recover database until cancel using backup controlfile
> > Mon Jul 12 11:54:41 1999 - Media Recovery Start
> > WARNING! Recovering data file 1 from a fuzzy file. If not the current
> > file
> > it might be an online backup taken without entering the begin backup
> > command.
> > WARNING! Recovering data file 2 from a fuzzy file. If not the current
> > file
> > it might be an online backup taken without entering the begin backup
> > command.
> > WARNING! Recovering data file 3 from a fuzzy file. If not the current
> > file
> > [...]
> > WARNING! Recovering data file 36 from a fuzzy file. If not the
> > current file
> > it might be an online backup taken without entering the begin backup
> > command.
> > Media Recovery Log
> > ORA-279 signalled during: alter database recover database until
> > cancel using...
> > Mon Jul 12 12:31:06 1999 -
> > alter database recover database until cancel using backup controlfile
> > Mon Jul 12 12:31:06 1999 -
> > Media Recovery Start
> > ORA-275 signalled during: alter database recover database until
> > cancel using...
> > Mon Jul 12 12:32:10 1999 -
> > alter database recover cancel
> > Mon Jul 12 12:32:10 1999 -
> > Incomplete recovery done UNTIL CHANGE 1099617362232
> > Media Recovery Cancelled
> > Completed: alter database recover cancel
> > ---------- end of trace file --------------
> >
> > Production database now is operating Ok, while.
> > Can anybody tell me, what I must to do to recover
> > second database using archivelog file from
> > production database.
> > Is it available? Or I must send all files from second
> > server to nul.
> >
> > Thank you in advance.
> > WBR, Alexander.
>