Export is NOT a backup

Amin Adatia wrote:
>
> Neil Greene wrote:
> >
> > In article <3397D5DA.7A4A_at_ats.nld.alcatel.nl>, ven_at_ats.nld.alcatel.nl
> > says...
> > > I am looking into the possibilities Oracle can give me
> > > to do 'hot backups'. From a developers point of view I don't
> > > have to do anything, except require that the database is started
> > > in the ARCHIVELOG mode. (at least that is what I read so far,
> > > if I am wrong in this assumption, please let me know).
> > >
> > > I am pretty sure that when I write the above as a conclusion
> > > I will immediately be getting responses (from within my company)
> > > saying that this solution is not workable because of performance issues.
> > > Therefor I am asking this group for 'field' experiences. Are there
> > > any reports or does anyone have experience that indicates that the
> > > performance of the Oracle database degrades (significantly) or
> > > hardly affects it when running in archivelog mode ?
> >
> > Ok, well tell your users who think they are so smart that "Yes, there is
> > some performance degradation." And there is also more performance
> > degradation while the system is unavailable for cold/offline backups.
> > So, you know have your spectrum from min to max.
> >
> > The thing to do is NOT to put all of your tablespace in backup mode at
> > the same time and perform online backups during periods of low activity
> > around your peak OLTP/BATCH schedules. There is/may be additional
> > performance hits taken while your backups are running from additional I/O
> > (I'd like the users to be able to notice this one) and from additional
> > rollback needed while tablespaces are in backup mode. But, like I said,
> > divide and conquer your online backups and your users won't notice.
> >
> > In addition, while your database is in ARCHIVELOG mode, you DO NOT HAVE
> > TO backup all of your datafiles every night. Split your tablespaces up
> > and backup different files over different days. For instance, on Monday,
> > do TBLS 1-50, on TUESDAY do TBLS 51-100, etc., etc. This reduces the
> > amount of time backing up. This may or may not meet your MTR strategies
> > though, but work on what is best for your environment. -- neil
> >
> > --
> > Neil Greene Senior System Engineer / Oracle DBA
> > MCI Systemhouse, Inc. <mailto:ngreene_at_laoc.SHL.com>
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: 2.6.2
> >
> > mQCNAzNWiBwAAAEEALmJ2Zho8BRcFc6vOHuUJp1TJ4+fZsmDgvi57DfDcnVCIcEv
> > e//qQ185dRN03821V7+MwfdKT51KOFcKRnHKFe8xGdDgMCB73ZFUn6X0acn3dVKn
> > K7kSTLpjcqlwGcEQb5MsH2oPz2ejUZ4+BghTN66nrZsEptkZOI+PVZH4HYSBAAUR
> > tCJOZWlsIEdyZWVuZSA8bmdyZWVuZUBsYW9jLlNITC5jb20+
> > =kEst
> > -----END PGP SIGNATURE---------------
> Hi!
>
> If you "never" shutdown the database, then the thing to do would be a
> export with the consistent_falg = Y. If this can be scheduled during
> non-peak periods then there should be a low penalty.
>
> Regards
> --
> Amin Adatia
> KnowTech Solutions Inc ( amin_at_istar.ca (613)226-8378 )
> at Parametric Technology Corporation (617)398-6332

The problem with export is it does not support recovery.

-- 
John P. Higgins      Voice:    (309)765-7868
Deere & Company      Fax:      (309)765-7800
John Deere Road      Internet: jh33378nospam_at_deere.com
Moline, IL 61265     Opinions: My Own