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
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 it at
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]
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
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:
