Hi Dick...
Along the lines of your last comments... Instead of waiting for Oracle,
you can implement a home grown solution... First, create a external
procedure that removes a file from the OS... Then, create a procedure
that...
Accepts tablespace name ( and maybe cascade option choice )
Determines all datafiles associated with the tablespace
Drops that tablespace
Executes the external procedure to remove the associated datafile(s) from
the OS
Of course you need to be VERY careful in writing this...
:-)
Tim
-----Original Message-----
Sent: Friday, November 02, 2001 10:06 AM
To: Multiple recipients of list ORACLE-L
Guy,
Not as problem, I've been called a whole lot worse in the past. Also,
nice
piece if info on the old monks, and yeah that is one heck of a DB recovery
or
more likely a resurrection.
Now to your point, when the datafile/tablespace gets dropped Oracle
first
off won't let you simply drop it if there are objects therein. You've got
to
use the 'cascade' option which does what you should have done in the first
place, namely drop all of those tables/indexes. Actually one presenter at
the
NorthEast Oracle Users Group once said that we were 'not too bright' if we
used
the 'cascade' option. In his mind it was much more efficient to drop all of
the
objects/segments manually first and then drop the tablespace. Whatever,
it's
the same thing. This being the case you've not only affected the control
files
you've also affected the system tablespace and made a significant change in
the
SCN of the database. This is because DDL statements, which 'drop
tablespace' is
part of, implicitly commit when they are done. Now where do you think good
old
Oracle keeps track of the SCN? In the tablespace header block, datafile
header
block and each affected segment block header. But since we're 'dropping'
this
tablespace do you think Oracle will update those as well? NAW, it saves a
pile
of writes, so all they do is flush out any 'pending' DBWR activity and then
release the file. What happen thereafter is of no concern. So if you want
to
'reassociate' the file with the database you have to either 'clean and reset
the
files clock' or else recover the database.
In many ways, I look at a database as a 'living' entity which marks time
like the rest of us. And just as we could not get along with an arm that
was 5
minutes behind us, so the database has to have all of it's arms, otherwise
known
as tablespaces, all at the same time point. That being the case, if you
loose
an arm, you can't just pick it back up again, you have to grow a new one.
On
the other hand, Oracle could just as easily issue the
remove(<datafile>); function on the OS side to clean up the mess. That
would
also eliminate a number of 'AW SH&&' explosions running around the place
when 1
second after you hit the <enter> key you realize you deleted an inuse
datafile
by mistake.
Dick Goulet
President of the Fat Finger Club
____________________Reply Separator____________________
Author: "Guy Hammond" <[EMAIL PROTECTED]>
Date: 11/2/2001 6:20 AM
Hi Doug,
Thanks for the reply. Incidentally, they did use to use re-cycled
parchments, called palimpsests, in ancient times. There was a magazine
article I read recently about some writings of Aristotle (or one of his
students/descendants) being recovered. His manuscripts had been bleached
and re-used by monks producing illustrated bibles - but his technology
was superior, and he had used an ink that penetrated deeply into the
page whereas the monks' ink just stuck to the surface, so in modern
times, the original writing could be restored. Now *that's* a database
recovery!
So let's say I had a database, created a tablespace with one datafile,
created a user with a default of that tablespace, did a bunch of
transactions, committed them, then dropped the tablespace. I know that
the datafile is "compatible" with the instance, because it came from
there. The datafile contains all the data from the transactions. Is it
just useless now? Can the data be recovered back into the original
instance from this datafile?
I know I could get it back by recovering from the last hotbackup and
rolling forward with archived redo logs, but it just seems a little
strange that datafiles can be "orphaned" like this... Hmmm.
Cheers,
g
-----Original Message-----
Sent: 02 November 2001 14:05
To: Guy Hammond; Multiple recipients of list ORACLE-L
Guy,
The 'drop tablespace' command does a number of items. It purges the
data
dictionary of all references to that tablespace, removes the file
information
from the control file, closes the datafile(s) and releases them back to
the
operating system. All that being said, if you then want to reuse the
datafile
as a new tablespace then you have to wipe it. The simplest reason being
that
you may be using it in a database with a different block size. Look at
it this
way, if you were starting to write a new book, would you use a notepad
of erased
paper? If you did there might end up being some very interesting side
notes
running around.
Dick Goulet
____________________Reply Separator____________________
Author: "Guy Hammond" <[EMAIL PROTECTED]>
Date: 11/2/2001 5:40 AM
Hello all,
When a tablespace is dropped, the datafile is left on the disk. What
exactly is the drop tablespace command doing, and is there a way to get
that datafile and "re-attach" to a new tablespace in some way? For
example, creating a tablespace using that datafile, but without wiping
it, as the "reuse" clause does?
Thanks,
g
--
Guy Hammond
AVT Technologies
Classic House
174-180 Old Street
London EC1V 9BP
Desk: 020 7454 4174
Mobile: 07966 164687
Web: http://www.avt.co.uk/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Guy Hammond
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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.com
--
Author: Guy Hammond
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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.com
--
Author: Johnston, Tim
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).
