Skip to Main Content
  • Questions
  • Impact of NOLOGGING on recovery and Data Guard

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question.

Asked: December 09, 2010 - 9:15 am UTC

Last updated: August 17, 2011 - 4:42 pm UTC

Version: 10.2.0.3

Viewed 10K+ times! This question is

You Asked

Tom,
We have a production database running in archivelog mode. In this database, there are certain tables which hold transient data. These tables are truncated every night, new data loaded into these tables, the data is then cleansed and transferred into regular application tables. The data is loaded from flat files using SQL Loader direct path load. This data is not critical in that if we lose it, we can always reload from flat files.

We have done some testing and found that if we switch these tables into NOLOGGING mode, we save lot of time loading data. My questions are:
a) How does the presence of tables in NOLOGGING mode effect our ability to be able to recover this database from backup?

b) If we implement Data Guard in future (either physical or logical), does the presence of tables in NOLOGGING mode stop us from doing that?

Thanks...

and Tom said...

a) it would affect these segments - these segments would not be recoverable after the non-recoverable operation. So, if you can survive the loss of these tables - no problem. It sounds like you can.

b) no, it wouldn't. However, it is recommended to use force logging (so the nologging would stop working) just to make it "safer" - so that no un-noticed (but bad) nologging operations take place.


Rating

  (6 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

New questions?

A reader, December 09, 2010 - 3:07 pm UTC

If you're not accepting new questions, how could this question have been asked 8 hours ago? I'm missing something here, where can I go to ask a new question?

Thank you!

Tom Kyte
December 10, 2010 - 9:53 am UTC

well, because 8 hours before you saw this question I was taking new questions.

I take about 10 at a time. Then the sign goes back up for "sorry..."

Tom is a busy man!

APH, December 09, 2010 - 4:01 pm UTC

It is a rare treat to get to ask Tom a question. You have to have some "lucky" timing. Typically the window for asking questions is on the order of minutes, not hours. If you query around you might find out when "good" times are to check if Tom is accepting new questions.

@The original question poster

Kim Berg Hansen, December 10, 2010 - 1:58 am UTC

Hi, anonymous

Just a suggestion that you possibly could avoid the transient tables completely.

You do:

1) New flat files arrive
2) Transient tables truncated
3) SQL Loader: flat files -> transient tables
4) Data cleansed: transient tables -> "real" tables

We have had much success with a different approach using external tables and materialized views. (I don't know your case sufficiently to know if it is possibly to use this approach in your case, but it might serve as inspiration :-)

We have created external tables on the flat files - that way we can select from the flat files.
Our data cleansing is possible to define in a single (albeit slightly complex) sql statement.
We create a materialized view refresh complete on demand defined by that cleansing sql statement.
The materialized view then becomes our production application table, on which we create suitable indexes etc.

Our scheduled work then becomes this:


1) New flat files arrive
2) Refresh materialized view

All done in two steps :-) Data is only moved once and it is done transactionally.

It is an approach that is good if the new flat files is a complete refresh of the data. If the flat files arriving are to be incrementally added to the data in your application tables, then it is not quite as neat :-)

Perhaps you can use some of the ideas.

To: Kim Berg Hansen

A reader, December 10, 2010 - 8:30 am UTC

At one time, we did explore the possibility of using external tables but there are some limitations which exclude their use. Today it is possible to workaround those limitations but no one wants to change a process which has worked for years.

To: A reader about new question

A reader, December 10, 2010 - 8:39 am UTC

I just got lucky. In fact, the slot for new questions was open for a while yesterday. I read this site regularly to refresh my Oracle knowledge and learn new features. Yesterday, when I opened the home page, I saw that Tom was taking new questions so I posted this question. Trust me, there is no short cut or backdoor to get questions in.

nologging with dataguard

Josh, August 17, 2011 - 2:35 pm UTC

In the oracle documentation at http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/scenarios.htm#i1015738 it says

"Even though the user specifies the clause, a redo record is still written to the online redo log file. However, there is no data associated with this record. This can result in log application or data access errors at the standby site and manual recovery might be required to resume applying log files."

In what scenarios would it result in an error? Lets say I have a transient table in a nologging tablespace. After I finish loading the data to the transient table, but before I've inserted into the permanent table, I need to switch to the physical standby database. I realize that the data won't be in the transient table, but will it error when I query it? How can I keep these transient tables in nologging and avoid errors if I fail over to the physical standby database? I know I'll need to reload that data, but is there anything that needs to be done before hand?
Tom Kyte
August 17, 2011 - 4:42 pm UTC

it would cause an error if you direct path loaded a table with nologging for example. You loaded the table (nologging), then someone updates lots of the rows.

When you failover - the loaded records don't exist, but the updates do. The table will appear corrupt and will be un-queryable.

If you have transient tables like this, you'll have to be prepared to recreate them when you fail over. A truncate should do it.