Re: strange temporary segment names
From: LS Cheng <exriscer_at_gmail.com>
Date: Sun, 7 Dec 2008 17:25:45 +0100
Message-ID: <6e9345580812070825v492686aap8d90f4f2a215b4ca@mail.gmail.com>
Date: Sun, 7 Dec 2008 17:25:45 +0100
Message-ID: <6e9345580812070825v492686aap8d90f4f2a215b4ca@mail.gmail.com>
Hi
I dumpped the blocks but I have no acess to the source so I cant determine if these objects exists in origin. Probably sometime next week i an get access :-S
The question is really how on earth these objects got to the destination when the tablespaces were transported. The tablespace were previously put in read only so tablespaces can be transportted therefore there shouldnt be any CTAS or index rebuild going on!
Thanks
-- LSC On Sun, Dec 7, 2008 at 4:00 PM, Stefan Knecht <knecht.stefan_at_gmail.com>wrote:Received on Sun Dec 07 2008 - 10:25:45 CST
> You can look at them by dumping the blocks -- maybe it will give you some
> clue wether it's a failed CTAS or some other operation ?
>
> alter system dump datafile <file_id> block min <block_id> block max
> <block_id+blocks-1>;
>
> The values you can get from dba_segments.
>
> Stefan
>
>
> =========================
>
> Stefan P Knecht
> Senior Consultant
> Systems Engineering
>
> OPITZ CONSULTING Schweiz GmbH
> Seestrasse 97
> CH-8800 Thalwil
>
> Mobile +41-79-571 36 27
> stefan.knecht_at_opitz-consulting.ch
> http://www.opitz-consulting.ch
>
> OCP 9i/10g SCSA SCNA
> =========================
>
>
>
> On Fri, Dec 5, 2008 at 12:22 PM, LS Cheng <exriscer_at_gmail.com> wrote:
>
>> Hello
>>
>> I have a database with some strange temporary segments under SYS schema
>> seen from dba_segments as follows:
>>
>> OWNER SEGMENT_TYPE
>> SEGMENT_NAME TABLESPACE_NAME
>> ------------------------------ ------------------
>> ------------------------------ ------------------------------
>> SYS TEMPORARY
>> 84.41971 TBS_DON_DATA
>> SYS TEMPORARY
>> 84.13427 TBS_DON_DATA
>> SYS TEMPORARY
>> 84.12659 TBS_DON_DATA
>>
>> I remember see these sort of names when a index is being rebuilt but this
>> is not the case. They are constantly there.
>>
>> This happened after transporting 3TB Tablespaces from a 10g database
>> running on Solaris to a 2 Nodes Linux x86-64 RAC running in 11g.
>>
>> any clues?
>>
>> Thanks
>>
>> --
>> LSC
>>
>>
>
>
-- http://www.freelists.org/webpage/oracle-l