Sorry, I forgot a Subject title!
Gurus,
I was just given a project to maintain a Computerized Maintenance
Management System. When I asked the companies support staff how to roll
back patches in the backend Oracle Database (Ver. 8174), they said that
there was no way to do this. I'm
Scott,
Of course, the answer is It depends.
It all depends on the kind of software patches that are being applied.
Are you talking about adding a column to a table that allows nulls? There
might not be a need to back this patch out - the column might be able to
stay depending on how it is used
Thanks to Thomas Mercadante, Stephen Lee and Rick Cale for their
responses. I think it's pretty unanimous that if this needs to be done, I
would just restore to the point in time taken right before the patches were
installed. Either I could do an export/restore/import or refresh from the
That is the recommended way. I have a 6 partition table with each partition
in a different tablespace and each table space on a different drive. It's
working well!
Ruth
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Wednesday, September 25, 2002
For any indexes on the table ,LOCAL prefixed indexes (b*tree/bitmap) is the preferred
way to go !
-Original Message-
Sent: Friday, September 27, 2002 7:18 AM
To: Multiple recipients of list ORACLE-L
tablespace,
That is the recommended way. I have a 6 partition table with each
Title: RE: Best Practice - Partitioned object, one partition per tablespace,
exactly - in the warehouse I am working on we have so much data over so many partitioned ranges (for the benefits of partition elimination) that it didn't make sense to create a separate part. in each tablespace plus
We currently are creating partitions of a given table in individual
tablespaces (1 partition = one tablespace). To me, this seems like a
reasonable practice. Anyone have any thoughts about this they would like the
share?
RF
Robert G. Freeman - Oracle OCP
Oracle Database Architect
CSX Midtier
Title: RE: Best Practice - Partitioned object, one partition per tablespace,
BTW, moving partitions from one tablespace to another is quick and easy so if later you have a real reason to have more tablespaces you can create them - our I/O configuration and access path did not warrant
Robert - That is how I've generally done it. If you are partitioning because
the table is very large, then separate tablespaces gives you the flexibility
to place these partitions on separate devices so you can get some parallel
I/O going.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
That's the way I've done it.
It let's you drop a partition and drop the tablespace
so nothing is left.
--- Freeman, Robert [EMAIL PROTECTED] a
écrit : We currently are creating partitions of a
given
table in individual
tablespaces (1 partition = one tablespace). To me,
this seems like a
it's what I'm planning on doing... seems to me that when we decide to
remove partitions, we can easily do so and retrieve the disk space this
way
--- Freeman, Robert [EMAIL PROTECTED] wrote:
We currently are creating partitions of a given table in individual
tablespaces (1 partition = one
Title: RE: Best Practice - Partitioned object, one partition per tablespace,
What if working on limited I/O so that striping is done at the OS level mostly. In this case there is no advantage to one partition - one tablespace and if there are many partitions it just gets hard to maintain
That's the strategy I have followed in my databases. Each table partition
and each index partition is in its own tablespace. Helps me a lot when I do
any maintenance operations. Partitioning is by 4 digit calendar year.
- Kirti
-Original Message-
Sent: Wednesday, September 25, 2002
Exactly the way we do it as well.
Each table and index partition are in their own tablespaces (indexes are
local and not global)
Regards
Lee
-Original Message-
Sent: 25 September 2002 20:54
To: Multiple recipients of list ORACLE-L
tablespace,
it's what I'm planning on doing... seems
We have a database which stores 5 years data with most
of the tables partitioned on year_month. We have three
tablespces each for each table, with tablespace_1
having 01,04,07,10 months and tablespace_2 having
2,5,8,11 and tablespace_3 having 3,6,9,12
--- Rachel Carmichael [EMAIL PROTECTED]
placing them in different tablespaces also allows you to place older
tablespaces into READ ONLY mode and reduce the volume of backups. also
permits moving less-frequently accessed tablespaces to near-line storage,
such as tape-based file-systems or CDROM...
- Original Message -
To:
Another approach is to partition according to your load strategy, but make
them reside in tablespaces according to how you want to set them to READ
ONLY.
For example, if you load daily, partition daily. But if you want to set the
data into READ ONLY to reduce backup volumes on a quarterly
PROTECTED]
Date: 3/28/2001 9:45 AM
Actually I meant Dick, nor Doug, sorry
Mike
-Original Message-
From: Lanteigne, Mike [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, March 28, 2001 8:35 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: What is best practice - differe
-Original Message-
From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2001 12:56 PM
To: Multiple recipients of list ORACLE-L
Subject: Re:What is best practice - differenet schema/different dbs
Rao,
I'm going to differ from a previous return
databases separated from the
other OLTP databases?
Thanks
Mike Lanteigne
-Original Message-
From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2001 12:56 PM
To: Multiple recipients of list ORACLE-L
Subject: Re:What is best practice - differenet
Actually I meant Dick, nor Doug, sorry
Mike
-Original Message-
From: Lanteigne, Mike [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, March 28, 2001 8:35 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: What is best practice - differenet schema/different dbs
Hi Doug
List,
I would like to have your opinion on the following scenario.
We are having an application which is used by different customers (around 15
customers). On an average each customer will have around 1,000 transactions
per 5 minutes. Now, is it better to have a separate database for each
Hi Maheswara,
I would think seperate databases would be the way to go, if for no other
reason, you can bring one customer offline without affecting the others.
-Rocky
--- "Rao, Maheswara" [EMAIL PROTECTED] wrote:
List,
I would like to have your opinion on the following scenario.
We are
Having separate databases gives you some flexibility. You can manage them
separatly, for instance you can upgrade the database to a newer version in
phase. Also, if you lose a database only one customer is affected. Do all
the customers always use the same application (same version)? If one
Rao,
I'm going to differ from a previous return post. I think that you should
use different schema's with separate tablespaces. Why? Because your all on one
machine therefore all of your background Oracle processes are competing for the
same CPU, memory, and IO resources which can and
Hi !
It all depends on your OPTIMIZER_MODE. I guess you
will be using CHOOSE and if that is the case I would recommend
analyzing the tables indexes (or ANALYZE_SCHEMA) for
+ or - 10 % change.
- Original Message -
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, March 25,
For Analyze of Tables on a Oracle 817 Database on Cluster with OPS ?
Should the Tables be Analyzed OR Not ?
This is a Application with More OLTP than Batch ( Banking Product )
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: VIVEK_SHARMA
INET: [EMAIL PROTECTED]
27 matches
Mail list logo
