Re: RECOVER DATABASE question again.

Hi,

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.
3. While taking offline backups, do a shutdown normal. Do not backup the files after doing a shutdown abort.
4. 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 <378b3a03.0_at_ns.mosbb.com>,
  "Alexander Chupin" <chupin_at_mail.mosbb.com> wrote:
> Hi,
>
> 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_at_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.

--
Denny Koovakattu
denny_at_vitalsol.com
http://vitalsol.com/

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Tue Jul 13 1999 - 13:44:17 CDT