Re:RE: reattaching datafiles

From: <dgoulet_at_vicr.com>
Date: Fri, 02 Nov 2001 06:58:19 -0800
Message-ID: <F001.003BB556.20011102070601@fatcity.com>

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" <guy.hammond_at_avt.co.uk>
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,

-----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" <guy.hammond_at_avt.co.uk>
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,

--

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: guy.hammond_at_avt.co.uk

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: ListGuru_at_fatcity.com (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: guy.hammond_at_avt.co.uk

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

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