date:20031024

Re: RMAN Incremental

2003-10-24 Thread Tim Gorman

Title: Re: RMAN Incremental



Michael,

Another good treatment of the use of partitioning in DW to reduce backups is a paper by Jeff Maresh posted online at “http://www.EvDBT.com/papers.htm”, entitled “Managing the Data Lifecycle”.

-Tim

on 10/24/03 4:34 PM, Michael Kline at [EMAIL PROTECTED] wrote:

I'm working at a Data Warehouse and they are looking for backup possibilities... 
 
This is almost a TB, a baby, and it may be that RMAN with incremental could be a good solution.
 
If say for instance there is a single tablespace of some 100 gig and they add 200,000,000 records to one of the tables and we do an incremental backup. Is the whole tablespace slated for backup?
 
Also if this tablespace was lost, and we recover.. What happens during that process? Does RMAN basically have to filter through two complete copies of that tablespace or just once and then get changed blocks?
 
What solutions have some doing this found to be "best practice"?
 
Thanks.

Michael Kline, Principal Consultant
Business To Business Solutions, LLC
Richmond, VA
804-744-1545

Re: Refresh option for Materialized view , want to use it during refresh - for

2003-10-24 Thread Arup Nanda

> i thought they might load faster because of fast refresh.

If you can do fast refresh, then MVs may be better. However, here are a few
considerations before you do so:

1. Fast refresh requires creation of mv logs on the master tables, which are
populated by triggers. This will affect performance on your source db, which
might not be acceptable.
2. Fast refresh is transactional, and it may be slower. If the number of
changes are large between two refreshes, it might be actually faster to do a
full refresh.

> not sure if we can do that across a db link.

Of course you can across db links. Fast refreshable MVs are also created in
replication environments; how do you suppose they work between two different
databases?

HTH.

Arup

- Original Message - 
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 11:49 PM
refresh - for


> no we dont need query rewrite. we load data every night across a database
> link. we drop and recreate all the tables from scratch. I thought about
> using materialized views. i thought they might load faster because of fast
> refresh. not sure if we can do that across a db link.
> - Original Message -
> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> Sent: Friday, October 24, 2003 10:14 PM
> refresh - for
>
>
> > No, you didn't read it completely. Create table and create MV do the
same
> > thing - produce a copy of the data on a different location (or a
different
> > segment) that can be queried independently. However, I proposed a
> different
> > way of doing the MV creating and refreshing, not using the
> > dbms_mview.refresh procedure as documented, but by using prebuilt table
> and
> > using other faster methods such as CTAS and Direct Path load to do a
> > complete refresh. It offers severa advantages such as faster execution,
> much
> > less outage window and low resource utilization. As an added bonus, you
> > don't have to drop and recreate the read only MV when you add/alter a
> column
> > to the master table.
> >
> > In your case, you might want to consider converting the tables to MV if
> MVs
> > are used in such a way. One example is if you see some benefit from
Query
> > Rewrite, you may want to create the MVs on the tables using the ON
> PREBUILT
> > TABLE clause for Oracle to use QR.
> >
> > HTH.
> >
> > Arup Nanda
> > www.proligence.com
> >
> > - Original Message -
> > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> > Sent: Friday, October 24, 2003 9:24 PM
> > refresh - for
> >
> >
> > > did i read that correctly that create table as is superior to a
> > materialized
> > > view for nightly loads? We drop all the tables in some of our schemas
> and
> > > rebuild them with create table as statements. I was going to try out
> > > materialized views to see if they were faster.
> > >
> > > guess they are not?
> > > - Original Message -
> > > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> > > Sent: Friday, October 24, 2003 12:34 PM
> > > refresh - for
> > >
> > >
> > > > Hi Arup,
> > > >
> > > > This is a very good method.  I would like to use it to modify some
of
> my
> > > > data loading procedures.  Here are my questions:
> > > > 1. Do I need to create the table on the step 1 every time when I
> refresh
> > > the
> > > > data If I refresh data once per day?
> > > > 2. Is "ON PREBUILT TABLE" available on Oracle 8i?  When I was trying
> the
> > > > method on Oracle 8i, I got missing keyword error on "PREBUILT".
> > > >
> > > > Dave
> > > >
> > > > >
> > > > >Siddharth,
> > > > >
> > > > >I will offer a slightly out-of-the-box solution. Please read it
> through
> > > > >till the end to determine its applicability in your case.
> > > > >
> > > > >It seems yours refresh interval is once a day and you don't mind
> stale
> > > > >data for a max of 24 hours. You also refresh is complete, not
> > > > >incremental. So, I would suggest the follwoing approach.
> > > > >
> > > > >(1) Create a table first
> > > > >CREATE TABLE CT_PRODUCTID_VW
> > > > >TABLESPACE 
> > > > >NOLOGGING
> > > > >AS
> > > > >SELECT .
> > > > >
> > > > >(2) When you are ready to "refresh", drop the MV
> > > > >DROP MATERIALIZED VIEW CT_PRODUCTID_VW;
> > > > >
> > > > >(3) Create the MV with the PREBUILT TABLE option.
> > > > >CREATE
> > > > >MATERIALIZED VIEW CT_PRODUCTID_VW
> > > > >BUILD IMMEDIATE
> > > > >REFRESH START WITH SYSDATE
> > > > >NEXT (SYSDATE + 1)
> > > > >ON PREBUILT TABLE
> > > > >AS
> > > > >SELECT
> > > > > msi.segment1productid,
> > > > >...
> > > > >
> > > > >Your MV is not accessible between STEP 2 and STEP3, which is really
a
> > > > >dictionary update and takes about a second or so. So the "outage"
is
> > > > >really 1 second, not 1/2 hr.
> > > > >
> > > > >A few explanations are in order here.
> > > > >
> > > > >(1) Creating an MV on a Prebuilt Table does not consume more space.
> The
> > > > >segment that used to be a table simp

Re: Refresh option for Materialized view , want to use it during refresh - for

2003-10-24 Thread Ryan

no we dont need query rewrite. we load data every night across a database
link. we drop and recreate all the tables from scratch. I thought about
using materialized views. i thought they might load faster because of fast
refresh. not sure if we can do that across a db link.
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 10:14 PM
refresh - for


> No, you didn't read it completely. Create table and create MV do the same
> thing - produce a copy of the data on a different location (or a different
> segment) that can be queried independently. However, I proposed a
different
> way of doing the MV creating and refreshing, not using the
> dbms_mview.refresh procedure as documented, but by using prebuilt table
and
> using other faster methods such as CTAS and Direct Path load to do a
> complete refresh. It offers severa advantages such as faster execution,
much
> less outage window and low resource utilization. As an added bonus, you
> don't have to drop and recreate the read only MV when you add/alter a
column
> to the master table.
>
> In your case, you might want to consider converting the tables to MV if
MVs
> are used in such a way. One example is if you see some benefit from Query
> Rewrite, you may want to create the MVs on the tables using the ON
PREBUILT
> TABLE clause for Oracle to use QR.
>
> HTH.
>
> Arup Nanda
> www.proligence.com
>
> - Original Message -
> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> Sent: Friday, October 24, 2003 9:24 PM
> refresh - for
>
>
> > did i read that correctly that create table as is superior to a
> materialized
> > view for nightly loads? We drop all the tables in some of our schemas
and
> > rebuild them with create table as statements. I was going to try out
> > materialized views to see if they were faster.
> >
> > guess they are not?
> > - Original Message -
> > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> > Sent: Friday, October 24, 2003 12:34 PM
> > refresh - for
> >
> >
> > > Hi Arup,
> > >
> > > This is a very good method.  I would like to use it to modify some of
my
> > > data loading procedures.  Here are my questions:
> > > 1. Do I need to create the table on the step 1 every time when I
refresh
> > the
> > > data If I refresh data once per day?
> > > 2. Is "ON PREBUILT TABLE" available on Oracle 8i?  When I was trying
the
> > > method on Oracle 8i, I got missing keyword error on "PREBUILT".
> > >
> > > Dave
> > >
> > > >
> > > >Siddharth,
> > > >
> > > >I will offer a slightly out-of-the-box solution. Please read it
through
> > > >till the end to determine its applicability in your case.
> > > >
> > > >It seems yours refresh interval is once a day and you don't mind
stale
> > > >data for a max of 24 hours. You also refresh is complete, not
> > > >incremental. So, I would suggest the follwoing approach.
> > > >
> > > >(1) Create a table first
> > > >CREATE TABLE CT_PRODUCTID_VW
> > > >TABLESPACE 
> > > >NOLOGGING
> > > >AS
> > > >SELECT .
> > > >
> > > >(2) When you are ready to "refresh", drop the MV
> > > >DROP MATERIALIZED VIEW CT_PRODUCTID_VW;
> > > >
> > > >(3) Create the MV with the PREBUILT TABLE option.
> > > >CREATE
> > > >MATERIALIZED VIEW CT_PRODUCTID_VW
> > > >BUILD IMMEDIATE
> > > >REFRESH START WITH SYSDATE
> > > >NEXT (SYSDATE + 1)
> > > >ON PREBUILT TABLE
> > > >AS
> > > >SELECT
> > > > msi.segment1productid,
> > > >...
> > > >
> > > >Your MV is not accessible between STEP 2 and STEP3, which is really a
> > > >dictionary update and takes about a second or so. So the "outage" is
> > > >really 1 second, not 1/2 hr.
> > > >
> > > >A few explanations are in order here.
> > > >
> > > >(1) Creating an MV on a Prebuilt Table does not consume more space.
The
> > > >segment that used to be a table simply becomes an MV.
> > > >(2) When you drop the MV, the MV is gone, but the table remains
> instact.
> > > >(3) The table can be create by any means - export/import, SQL*Loader,
> > > >INSERT APPEND, etc.
> > > >(4) IT places less strain on the system comapred to the MV refresh
> > > >option, simply because the MV refresh truncates the segment and then
> > > >builds it.
> > > >
> > > >I presented a paper to the same effect at IOUG Live 2003. You can
> > > >download a modified version of the same from my website
> > > >www.proligence.com/downlaods.html, titled "Painless Master Table
Alter"
> > > >from the Presentations Section.
> > > >
> > > >HTH.
> > > >
> > > >Arup Nanda
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >- Original Message -
> > > >To: Multiple recipients of list ORACLE-L
> > > >Sent: Tuesday, October 21, 2003 3:59 AM
> > > >refresh
> > > >
> > > >
> > > >Hi Gurus,
> > > >
> > > >I have a materialized view, which is based on Oracle Apps tables and
on
> > > >remote database. The view refresh takes around ½ hour, during this
time
> > > >period I cannot see any records in the materi

Re: re Rebuilding Indexes in Oracle Apps -- was RE: RE:

2003-10-24 Thread Richard Foote

Hi Hemant,

How I dislike being immortalised ;)

The note basically quoted me word for word on my feedback and that's fine,
it's certainly an improvement on what was previously suggested (and yes,
Oracle asked for my permission).

A point I would add though is that the whole subject of how Oracle indexes
function and the various cases when one should or should not rebuild indexes
is not black and white and is not easily covered in a couple of paragraphs.
There are always exceptions and oddities, the key is determining when these
scenarios arrive and taking the appropriate action. Many books/articles
emphasise the need to rebuild generally and often, I'm suggesting the
emphasis should be far more considered and "practical".

If anyone reading the note now questions the rebuild generally and often
approach, then my comments serve their intentions.

Cheers

Richard

- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 1:19 AM


>
> Yes.  However, every time he has replied to me, he has been confident that
he
> IS right.
>
> Mind you, Richard, you are "immortalised" now !
> Hemant
>
> At 05:04 PM 22-10-03 -0800, you wrote:
> >So now the blame rests solely on Richard for any material in the note
that's
> >wrong.  :)
> >
> >Check the latest update:
>
>http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_data
b
> >ase_id=NOT&p_id=182699.1
> >
> >Pete
> >"Controlling developers is like herding cats."
> >Kevin Loney, Oracle DBA Handbook
> >"Oh no, it's not.  It's much harder than that!"
> >Bruce Pihlamae, long-term Oracle DBA
> >
> >
> >
> >-Original Message-
> >Millsap
> >Sent: Wednesday, October 22, 2003 2:35 AM
> >To: Multiple recipients of list ORACLE-L
> >
> >
> >Oops, I didn't see that part. Thanks for the catch, Hemant.
> >
> >
> >Cary Millsap
> >Hotsos Enterprises, Ltd.
> >http://www.hotsos.com
> >
> >Upcoming events:
> >- Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney
> >- SQL Optimization 101: 12/8-12 Dallas
> >- Hotsos Symposium 2004: March 7-10 Dallas
> >- Visit www.hotsos.com for schedule details...
> >
> >
> >-Original Message-
> >Hemant K Chitale
> >Sent: Tuesday, October 21, 2003 10:15 AM
> >To: Multiple recipients of list ORACLE-L
> >
> >
> >Unfortunately, the lines
> >"Unoccupied space on indexes occurs when a key value changes, and
> >the
> >index
> >  row is deleted from one place (Leaf Block) and inserted into
another.
> >  Deleted Leaf Rows are not reused.  Therefore, indexes whose columns
are
> >  subject to intensive value change should be rebuilt periodically,
since
> >  they become naturally fragmentated. "
> >are still visible in Note 182699.1
> >
> >Hemant
> >
> >At 08:29 AM 20-10-03 -0800, you wrote:
> > >Fyi, Oracle updated note 182699.1 last Friday. The inaccurate
> >statements
> > >about "index fragmentation" have been removed.
> > >
> > >
> > >Cary Millsap
> > >Hotsos Enterprises, Ltd.
> > >http://www.hotsos.com
> > >
> > >Upcoming events:
> > >- Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney
> > >- SQL Optimization 101: 12/8-12 Dallas
> > >- Hotsos Symposium 2004: March 7-10 Dallas
> > >- Visit www.hotsos.com for schedule details...
> > >
> > >
> > >-Original Message-
> > >Richard Foote
> > >Sent: Friday, October 17, 2003 6:29 AM
> > >To: Multiple recipients of list ORACLE-L
> > >Separate
> > >
> > >Hi Hemant,
> > >
> > >One word perfectly describes the Metalink article you highlighted:
> > >
> > >Crap ;)
> > >
> > >A nice example of  how Oracle Corp is the greatest myth generator of
> > >them all !! It's all rather sad and embarressing isn't.
> > >
> > >Thanks for the headsup. Anyone in a position to get the note removed ?
> > >
> > >Cheers
> > >
> > >Richard
> > >
> > > >Quoting Metalink Note 182699.1 bde_rebuild.sql Validates and Rebuilds
> > >Fragmentated Indexes (8.0->9.0)
> > > >
> > > >Index fragmentation occurs when a key value changes, and the index
> >row
> > >is
> > > >deleted from one place (Leaf Block) and inserted into another.
> > > >
> > > > Deleted Leaf Rows are not reused. Therefore indexes whose columns
> >are
> > >  >subject to value change must be rebuilt periodically since they
> >become
> > >naturally fragmentated.
> > > >
> > >  >An index is considered to be 'fragmentated' when more than 20% of
> >its
> > >Leaf
> > >Rows space is
> > > >empty because of the implicit deletes caused by indexed columns value
> > >changes.
> > > >
> > >  >Fragmentated indexes degrade the performance of index range scan
> > >operations.
> > >
> > >
> > >--
> > >Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > >--
> > >Author: Richard Foote
> > >   INET: [EMAIL PROTECTED]
> > >
> > >Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> > >San Diego, California-- Mailing list and web hosting services
> > >-
> > >To REMOVE yourself

Re: VPN to database?

2003-10-24 Thread Arup Nanda

Paul,

We use Advanced Security. the product is pricey and difficult to setup; but
once in place it's in solid footing.

Advanced security does not replace VPN per se; it's purpose is slightly
different and broader in scope. If you take VPN away, how do you suppose you
will connect to the DB server, directly? Hardly. So, VPN _may_ be required
regardless.

Some of the uses of AS are (not exhaustive)

1. Encryption and Checksumming of Net8 connection between the db server and
the app servers (and any other users connected to the db server directly).
This is the bare minimum security manadated by HIPAA and unfortunately
Oracle does not provide a solution as a part of the base product. You may
not need it, though; since using intelligent subnets and using firewalls
around the db servers can limit threats to an acceptable degree.

2. Single signon. We use it in our app servers (running IIS) where the
authentication is done using certificates. Again, this is necessary due to
the refusal of the Development group to introduce database userids and
eliminate the application authentication.

The second part can be addressed in a different way. Using an application
user security model where the users supply their userid and password to the
database for authentication will eliminate the need to have a Windows user
to be authenticated. A simple mechanism will be to authenticate the user
agaist the database as the very first step. If authentication fails, the app
will not proceed further. This will eliminate the authentication of the user
by Windows. This model has been in use on a different app here and works
great; but on the other app, the manager insists on one authentication on
Windows and then another on the database, hence single signon.

HTH.

Arup Nanda
www.proligence.com

- Original Message - 
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 10:09 PM


> Thanks, everyone, for your helpful responses.
>
> A talk with our Oracle sales droid has pointed me in the direction of
> Oracle Advanced Security for authentication, encryption, and integrity.
>  Anyone have experience using this?  We are considering using Entrust
> SSL authentication as we already use Entrust to authenticate users of
> our app.  Would Advanced Security replace a VPN, or coexist with it?
>
>
>
> =
> Paul Baumgartel
> Transcentive, Inc.
> www.transcentive.com
>
> __
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: Paul Baumgartel
>   INET: [EMAIL PROTECTED]
>
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
>
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Arup Nanda
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Re: Refresh option for Materialized view , want to use it during refresh - for

2003-10-24 Thread Arup Nanda

No, you didn't read it completely. Create table and create MV do the same
thing - produce a copy of the data on a different location (or a different
segment) that can be queried independently. However, I proposed a different
way of doing the MV creating and refreshing, not using the
dbms_mview.refresh procedure as documented, but by using prebuilt table and
using other faster methods such as CTAS and Direct Path load to do a
complete refresh. It offers severa advantages such as faster execution, much
less outage window and low resource utilization. As an added bonus, you
don't have to drop and recreate the read only MV when you add/alter a column
to the master table.

In your case, you might want to consider converting the tables to MV if MVs
are used in such a way. One example is if you see some benefit from Query
Rewrite, you may want to create the MVs on the tables using the ON PREBUILT
TABLE clause for Oracle to use QR.

HTH.

Arup Nanda
www.proligence.com

- Original Message - 
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 9:24 PM
refresh - for


> did i read that correctly that create table as is superior to a
materialized
> view for nightly loads? We drop all the tables in some of our schemas and
> rebuild them with create table as statements. I was going to try out
> materialized views to see if they were faster.
>
> guess they are not?
> - Original Message -
> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> Sent: Friday, October 24, 2003 12:34 PM
> refresh - for
>
>
> > Hi Arup,
> >
> > This is a very good method.  I would like to use it to modify some of my
> > data loading procedures.  Here are my questions:
> > 1. Do I need to create the table on the step 1 every time when I refresh
> the
> > data If I refresh data once per day?
> > 2. Is "ON PREBUILT TABLE" available on Oracle 8i?  When I was trying the
> > method on Oracle 8i, I got missing keyword error on "PREBUILT".
> >
> > Dave
> >
> > >
> > >Siddharth,
> > >
> > >I will offer a slightly out-of-the-box solution. Please read it through
> > >till the end to determine its applicability in your case.
> > >
> > >It seems yours refresh interval is once a day and you don't mind stale
> > >data for a max of 24 hours. You also refresh is complete, not
> > >incremental. So, I would suggest the follwoing approach.
> > >
> > >(1) Create a table first
> > >CREATE TABLE CT_PRODUCTID_VW
> > >TABLESPACE 
> > >NOLOGGING
> > >AS
> > >SELECT .
> > >
> > >(2) When you are ready to "refresh", drop the MV
> > >DROP MATERIALIZED VIEW CT_PRODUCTID_VW;
> > >
> > >(3) Create the MV with the PREBUILT TABLE option.
> > >CREATE
> > >MATERIALIZED VIEW CT_PRODUCTID_VW
> > >BUILD IMMEDIATE
> > >REFRESH START WITH SYSDATE
> > >NEXT (SYSDATE + 1)
> > >ON PREBUILT TABLE
> > >AS
> > >SELECT
> > > msi.segment1productid,
> > >...
> > >
> > >Your MV is not accessible between STEP 2 and STEP3, which is really a
> > >dictionary update and takes about a second or so. So the "outage" is
> > >really 1 second, not 1/2 hr.
> > >
> > >A few explanations are in order here.
> > >
> > >(1) Creating an MV on a Prebuilt Table does not consume more space. The
> > >segment that used to be a table simply becomes an MV.
> > >(2) When you drop the MV, the MV is gone, but the table remains
instact.
> > >(3) The table can be create by any means - export/import, SQL*Loader,
> > >INSERT APPEND, etc.
> > >(4) IT places less strain on the system comapred to the MV refresh
> > >option, simply because the MV refresh truncates the segment and then
> > >builds it.
> > >
> > >I presented a paper to the same effect at IOUG Live 2003. You can
> > >download a modified version of the same from my website
> > >www.proligence.com/downlaods.html, titled "Painless Master Table Alter"
> > >from the Presentations Section.
> > >
> > >HTH.
> > >
> > >Arup Nanda
> > >
> > >
> > >
> > >
> > >
> > >- Original Message -
> > >To: Multiple recipients of list ORACLE-L
> > >Sent: Tuesday, October 21, 2003 3:59 AM
> > >refresh
> > >
> > >
> > >Hi Gurus,
> > >
> > >I have a materialized view, which is based on Oracle Apps tables and on
> > >remote database. The view refresh takes around ½ hour, during this time
> > >period I cannot see any records in the materialized view and therefore
> > >my application faces errors.
> > >The following is the view definition
> > >
> > >CREATE
> > >MATERIALIZED VIEW CT_PRODUCTID_VW
> > >BUILD IMMEDIATE
> > >REFRESH START WITH SYSDATE
> > >NEXT (SYSDATE + 1)
> > >AS
> > >SELECT
> > > msi.segment1productid,
> > > msi.description description,
> > > msi.inventory_item_id   inventory_item_id,
> > > mc.segment1 product_family,
> > > mc.segment2 product_type
> > >FROM [EMAIL PROTECTED]  mcs,
> > >  [EMAIL PROTECTED] mc,
> > >  [EMAIL PROTECTED]mic,
> > >  [EMAIL PROTECTED]

Michael,
I hope you have the tables partitioned on some date
column. You can make some of the older partitions read only and back them up
only once.
Another solution is to exchange the partitions with
a table to convert your old partitions to tables, transporting them to a tape
and keep it on the tape. If the database crashed, you will plug these TSs back
to the DB and exchange the partitions with the tables created
earlier.
I presented a session at Oracle World this year
describing a case study of a datawarehouse where I have described the backup and
recovery approach. You can download it from OTN or from my website (www.proligence.com/downloads.html).
Be sure to download both the paper and the presentation.
HTH.
Arup Nanda

- Original Message -
From:
Michael
Kline
To: Multiple recipients of list ORACLE-L

Sent: Friday, October 24, 2003 7:34
PM
Subject: RMAN Incremental

I'm working at a
Data Warehouse and they are looking for backup possibilities...

This is almost a
TB, a baby, and it may be that RMAN with incremental could be a good
solution.
If say for
instance there is a single tablespace of some 100 gig and they add 200,000,000
records to one of the tables and we do an incremental backup. Is the whole
tablespace slated for backup?
Also if this
tablespace was lost, and we recover.. What happens during that process? Does
RMAN basically have to filter through two complete copies of that
tablespace or just once and then get changed blocks?
What solutions
have some doing this found to be "best practice"?
Thanks.

1 2 >

1 - 100 of 137 matches

Mail list logo