Title: RE: providing 24*7 database ---
Narender hasn't replied yet. But the sample I sent only uses local indexes since there is only one partition. I did see that Jim Conboy pointed out that I missed the 'including indexes' option.
Tony
-Original Message
et> cc:
Sent by: Subject: RE: providing 24*7 database ---
L PROTECTED]]Sent: Tuesday, October 23,
2001 10:30 PMTo: Multiple recipients of list
ORACLE-LSubject: RE: providing 24*7 database
---
Thanks all for the input.
hi
tony ,
Quick question ... when you exchange partititons with
non partitioned table data , all indexes on non partition
Title: RE: providing 24*7 database ---
I
couldn't verify that the non-partitioned indexes become unusable after
exchanging the partition for the normal table. In the sample I posted
I snipped the output of the queries on USER_INDEXES and USER_PART_INDEXES,
but my tests showed that
Title: RE: providing 24*7 database ---
Thanks
all for the input.
hi
tony ,
Quick
question ... when you exchange partititons with non partitioned table data , all
indexes on non partitioned tables become unusable status
right.
do
have to rebuild them after every exchnage...
naren
Sent by: Subject: RE: providing 24*7 database ---
[EMAIL PROTECTED]
Title: RE: providing 24*7 database ---
We use a modified version of your duplicate schema idea. But we don't have the objects in different schemas. We use partitioned objects so that we can exchange the partitions with the production tables at a scheduled time. The voodoo is that we
Title: RE: providing 24*7 database ---
Here is a link http://www.quest.com/whitepapers/ you can use to check out a couple of white papers on 24x7 shops and HA environments with Oracle. One very good one, that will help address your needs is this one... http://www.quest.com/whitepapers
Having been through (and still going through this)...
we use one for queries, one for loading, when the loads are done, we do
a backup then we switch the app to the "loading" database (coded so
that as long as someone is connected the app doesn't switch over).
once the app has switched, we down
The thing that immediately springs to mind would be to use two
databases, one for queries, one for loading. Then, when the data was
ready, use a transportable tablespace to plug it in. There might be some
post processing or redefining of views necessary. This is better than
using two schemas to do
Narender,
Transportable Tablespaces might allow you to load data in an offline
instance then quickly "plug in" the new data to the production instance.
Jack
Jack C. Applewhite
Database Administrator/Developer
OCP Oracle8 DBA
iNetProfit, Inc.
Austin, Texas
www.iN
Tim Gorman's paper
"Choosing Among High-Availability Architectures in Oracle"
at
www.evdbt.com/library.htm
might be useful. He lists options available and relative costs.
Good luck!
Barb
> --
> From: Narender Akula[SMTP:[EMAIL PROTECTED]]
> Reply To: [EMAIL PROTECTE
12 matches
Mail list logo