You actually are reinforcing my opinion.
Yes, we can do what you suggest – just backup the database files that we loaded. But why do it that way? Why have a backup policy for the entire database that may say we backup the entire database daily or ever other day, or just the archive logs in between a full backup, and then change the policy to say – oh wait a minute – we are going to just reloaded these two tables so I’m not going to enforce logging but I’ll do a special backup to cover my backside.
Why in the world would we want to do business this way? To save time?
I guess at some sites we (DBA’s) may be forced into this position by management. But I would argue strongly that these practices have a higher chance of data loss than just running things normally.
What does Gartner say is the leading cause of data loss? Human decisions – not hardware failure.
I guess I’m not risk tolerant.
From: Jared Still [mailto:email@example.com]
Sent: Monday, August 22, 2005 5:05 PM
To: Mercadante, Thomas F (LABOR)
Cc: firstname.lastname@example.org; email@example.com
Subject: Re: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against
On 8/22/05, Mercadante, Thomas F (LABOR) <Thomas.Mercadante@labor.state.ny.us> wrote:
I was thinking about this whole topic over the weekend. It just affirms my feeling that using the NOLOGGING option needs to be used judiciously. And I question how much time we are saving here.
Quite a bit of time actually. Try timing a bulk load operation with and without logging.
If the total time to reload using NOLOGGING and a total backup is less than a reload with LOGGING and no backup, then don't use it.
You don't need a complete database backup, just the datafiles containing the nologging objects.
Certifiable Oracle DBA and Part Time Perl Evangelist