PROTECTED]
*Sent:* Tuesday, October 14, 2003 5:44 AM
*Subject:* RE: RE: Separate Indexes and Data
Jared,
Any indexes supporting a In-Today; Gone-Tomorrow status table
will require index rebuilds. Most of them have monotonically
increasing numbers which lends itself to a 'holey
cans. But these are
generally *exceptions*, not the norm.
Hope this mail makes it ??
Cheers
Richard
- Original Message -
From:
John
Kanagaraj
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, October 14, 2003 5:44
AM
Subject: RE: RE: Separate Indexes an
PM 01:34:28 EDT
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Separate Indexes and Data
I'd be very interested to know how many people have their index
tablespaces on a different backup schedule from their data
tablespaces. If so how different? What
To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: RE: Separate Indexes and Data
I assume that what Rachel is referring to is the fact that indexes will
generally not release much space when the underlying rows are deleted. They
just keep growing, so
ate, Im thinking of waiting for version 10g before
using it. Just to be
safe. Not worth risking a defrag on a production system.
From: "MacGregor, Ian A."
[EMAIL PROTECTED] Date: 2003/09/30 Tue PM
01:34:28 EDT To: Multiple recipients of list ORACLE-L
[EMAIL PR
PROTECTED]
Date: 2003/09/30 Tue PM 01:34:28 EDT
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Separate Indexes and Data
I'd be very interested to know how many people have their index
tablespaces on a different backup schedule from their data
for version 10g before
using
it. Just to be safe. Not worth risking a defrag on a production
system.
From: MacGregor, Ian A. [EMAIL PROTECTED]
Date: 2003/09/30 Tue PM 01:34:28 EDT
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Separate Indexes and Data
recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Separate Indexes and Data
I'd be very interested to know how many people have their index
tablespaces on a different backup schedule from their data
tablespaces. If so how different? What happens when a media
failure occurs
-Original Message-
From: Jesse, Rich
Sent: Wednesday, October 01, 2003 9:49 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: locally managed autoallocate (was: Separate Indexes and
Data)
Theoritically, perhaps, but what if an existing table needs
to auto-extend
(was: Separate Indexes and
Data)
-Original Message-
From: Jesse, Rich
Sent: Wednesday, October 01, 2003 9:49 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: locally managed autoallocate (was: Separate
Indexes and
Data)
Theoritically, perhaps, but what
Couldn't you do this with a simple:
select
owner, table_name
from
all_tables
where
tablespace_name= 'index_tbs';
?
Or of
course use IN for a list of tablespaces?
Or am
I missing something?
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of
system.
From: MacGregor, Ian A. [EMAIL PROTECTED]
Date: 2003/09/30 Tue PM 01:34:28 EDT
To: Multiple recipients of list ORACLE-L
[EMAIL PROTECTED]
Subject: RE: Separate Indexes and Data
I'd be very interested to know how many people
have their index
tablespaces on a different backup
-Original Message-
From: Jacques Kilchoer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 7:34 PM
To: Multiple recipients of list ORACLE-L
Subject: locally managed autoallocate (was: Separate Indexes and Data)
Ive read the book. PCTINCREASE is basically set to 100
-Original Message-
From: Jesse, Rich
Sent: Wednesday, October 01, 2003 9:49 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: locally managed autoallocate (was: Separate Indexes and
Data)
Theoritically, perhaps, but what if an existing table needs
to auto-extend
at 1M
Part of the problem is self-inflicted. We currently use separate tablespaces for each
major project. For instance: chemical inventory gets its own data and index
tablespaces, dosimeter data gets the same, network configuration data as well. For
many projects once the design has matured
?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: 30 September 2003 22:45
To: Multiple recipients of list ORACLE-L
Subject: RE: Separate Indexes and Data
Good question Ian. If anyone does have a different
I'd be very interested to know how many people have their index tablespaces on a
different backup schedule from their data tablespaces. If so how different? What
happens when a media failure occurs and you must restore from backup? You would need
to have on hand and apply more redo logs to
PROTECTED]
Subject: RE: Separate Indexes and Data
I'd be very interested to know how many people have their index tablespaces on a
different backup schedule from their data tablespaces. If so how different? What
happens when a media failure occurs and you must restore from backup? You would
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 12:50 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: RE: Separate Indexes and Data
the defrag paper was written back in 1998 I believe. Uniform
extents were a good
From: Jesse, Rich [EMAIL PROTECTED]
Date: 2003/09/30 Tue PM 02:09:32 EDT
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: RE: Separate Indexes and Data
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30
recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Separate Indexes and Data
I'd be very interested to know how many people have their index
tablespaces on a different backup schedule from their data
tablespaces. If so how different? What happens when a media
failure occurs
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 1:29 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: RE: Separate Indexes and Data
From: Jesse, Rich [EMAIL PROTECTED]
Date: 2003/09/30 Tue PM 02:09:32 EDT
Hi!
In VLDB environments, it is mostly cheaper to restore and recover the index
tablespace datafile in case of block corruption. In my experience, I've been
lucky and have been able to get rid of corruptions that way, but I'm sure
some people have worse experiences, especially when redologs are
a defrag on a production system.
From: MacGregor, Ian A. [EMAIL PROTECTED]
Date: 2003/09/30 Tue PM 01:34:28 EDT
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Subject: RE: Separate Indexes and Data
I'd be very interested to know how many people have their index
tablespaces
respond to ORACLE-L
To:Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
cc:
Subject:RE: Separate Indexes and Data
I'd be very interested to know how many people have their index tablespaces on a different backup schedule from their data tablespaces. If so how
But those holes of exactly the right size for new objects to fit into.
Since you'll presumably move it once it gets about 1,000 extents or so that
isn't a huge amount of space that's being wasted.
Jay Miller
Sr. Oracle DBA
-Original Message-
Sent: Tuesday, September 30, 2003 4:45 PM
You can always schedule a script which drops all
table segments from index tablespaces ;)
Tanel.
- Original Message -
From:
[EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L
Sent: Wednesday, October 01, 2003 12:44
AM
Subject: RE: Separate Indexes
Ive read the book. PCTINCREASE is basically set to 100% so
the extent sizes double. Thats 'basically' how it works. I
have seen some posts on dejanews saying it doesnt necessarily
work this way and some people are finding large extent sizes
with just a few extents and when tables are
Yes, and there is one thing to add:
If you do not specify INTIAL, the extent allocation starts with 5 blocks for
the intial extent. For 8k, it's 40k, but in an autoallocating LMT extent
cannot be smaller then 64k, so it is the amount of the space allocated. The
interesting question is: what
29 matches
Mail list logo
