RE: Nologging and partition exchange
- From: <Paul.Baumgartel@xxxxxxx>
- To: <mwf@xxxxxxxx>, <tim@xxxxxxxxx>
- Date: Fri, 4 Jun 2010 11:39:00 -0400
So, let's say that we isolate all of the staging tables in a specific
tablespace. Would a regime of full (over the weekend, say) and
incremental (after the staging load) backups of that tablespace be
effective?
If the above approach was not possible for some reason, and let's say
that we didn't want to inject backup logic into the middle of the ETL
process, an incremental backup of the tablespaces holding the
partitioned tables after ETL is complete would be my next choice.
Paul Baumgartel
UBS AG
IB Accounting Solutions
400 Atlantic Street
Stamford, CT 06904
203.719.4368
paul.baumgartel@xxxxxxx
www.ubs.com
________________________________
From: Mark W. Farnham [mailto:mwf@xxxxxxxx]
Sent: Friday, June 04, 2010 11:15 AM
To: tim@xxxxxxxxx; Baumgartel, Paul
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: Nologging and partition exchange
And if... (meaning I agree completely with what is written so far...)
If you consider the partitioned object a live production object and the
preparatory table loaded nologging to be a "staging" object, then
preserving the recoverability of the staging object after loading but
before the exchange is a practice to consider. When the source data for
the "staging" table remains available at least through the preservation
of the recoverability of the staging object, these leaves you with no
point in time lacking a reasonable reprocessing workflow to follow when
something goes bump. And at no time do you give access to users to an
object that is not recoverable. While this does inject a lag between
loading the staging object and making the contained data part of the
production image, it does maintain the nologging advantage of minimizing
the redo stream. Overall backing up the relevant incremental routinely
produces less concurrency conflict amongst your hardware resources than
the affect of injecting the extra redo.
This may or may not fit with your real world requirements, but it is a
practice worth consideration.
mwf
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Gorman
Sent: Friday, June 04, 2010 9:54 AM
To: Paul.Baumgartel@xxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Nologging and partition exchange
Paul,
After any NOLOGGING operation, please perform an RMAN incremental
level=1 backup as soon as possible. Of course, level=0 or full is OK
too, but the minimum is a level=1. The time period between the
completion of the load and completion of the backup is a window of risk
of possible data loss in the event of media failure or corruption, and
that window of risk is the tradeoff (i.e. speed vs recoverability) that
must be consciously accepted using for the NOLOGGING operation.
Hope this helps...
Tim Gorman
consultant -> Evergreen Database Technologies, Inc.
postal => P.O. Box 630791, Highlands Ranch CO 80163-0791
website => http://www.EvDBT.com/
email => Tim@xxxxxxxxx
mobile => +1-303-885-4526
fax => +1-303-484-3608
Lost Data? => http://www.ora600.be/ for info about DUDE...
Paul.Baumgartel@xxxxxxx wrote:
When a table is loaded with NOLOGGING and /*+ APPEND */ hint, then
exchanged with a table partition, that partition remains unrecoverable,
correct?
If you use this approach, how do you make the partition recoverable?
Paul Baumgartel
UBS AG
IB Accounting Solutions
400 Atlantic Street
Stamford, CT 06904
203.719.4368
paul.baumgartel@xxxxxxx
www.ubs.com <file:///\\www.ubs.com>
-- //www.freelists.org/webpage/oracle-l
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mails are not encrypted and cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the
contents of this message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities
or related financial instruments.
UBS reserves the right to retain all messages. Messages are protected
and accessed only in legally justified cases.
Other related posts:
