not my call. i posted this on here before. was done that way before i got here. Its part of the transportable tablespace plan since you cant have multiple tablespaces with the same name in one instance.
 
I found some interesting(and troublesome things). I think Oracle may not be telling us the whole truth with how flushing the shared pool works and/or how the data dictionary data is stored in memory.
 
We update TS$ to rename a tablespace. Normally we have no problems. Occasionally we have to flush the shared pool in order to alter the tablespace to read only. It doesnt recognize the new name. We check TS$ and the new name is there. My best guess at what is happening is that the data in the dictionary cache has the old name and the data in the system datafile has the new name. We can query the data dictionary and this queries the actually datafile and does not flush the dictionary cache.
 
We flush the shared pool and everything works. However, for the second time flushing the shared pool has not worked. Interesting thing is that we can take the OLD tablespace name to read only, but not the new. We had everyone log out of the instance since we were wondering whether Oracle cached some data dictionary info in the PGA. We were able to bring the tablespace back online using its new name.
 
We then logged out and back in. Didnt work this time. Flushed the shared pool. Didnt work. So we bounced the instance and everything works. This leads me to the following conclusions.
 
1. Updating TS$ does not cascade to other tables. If that was so, bouncing the database should not have fixed our problem.
2. Flushing the shared pool does not 'necessarily' flush all of the data from the shared pool. Since Alter tablespace still recognized the old name of the tablespace.
3. Or Oracle is storing part of the data dictionary information in other parts of memory that it is abstracting from us and not releasing.
 
This was almost long enough to be an article... Anyone play around with this stuff? I know Steve Adams reads this forum periodically? you play with it? Some of you worked for Oracle, have you gotten and good inside info?
 
In spite of the problem, it is fairly interesting to see that Oracle isnt telling us everything. Makes you wonder what else they are 'abstracting' from us in the documentation.
----- Original Message -----
Sent: Friday, September 05, 2003 7:22 PM
Subject: Re: question for internals experts


Sounds like you want to rename a tablespace.

Not recommended without approval from Oracle support.

Jared




<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]

 09/05/2003 01:09 PM
 Please respond to ORACLE-L

       
        To:        Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
        cc:        
        Subject:        question for internals experts



Does oracle store the tablespace_name or any data about a tablespace anywhere else accept TS$?

Im looking for base data dictionary tables. Not views. Are there any documents out there about how oracle stores information in the data dictionary tables other than what Steve Adams has in his book or on his website? Has anyone else published on this?

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: <[EMAIL PROTECTED]
 INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).


Reply via email to