| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Transportable Tablespace, SCNs and ORA-1555s.
I thought that when you alter a tablespace to read only, there is a
checkpoint and all committed data is flushed out to disk.......my vote is
that it succeeds.
-----Original Message-----
From: Daniel Fink [mailto:Daniel.Fink_at_Sun.COM]
Sent: Wednesday, March 17, 2004 4:50 PM
To: oracle-l_at_freelists.org
Subject: Re: Transportable Tablespace, SCNs and ORA-1555s.
Why not?
When I set the ts to read only, the ITL entry still indicates an uncommitted transaction.
Daniel
Richard Ji wrote:
> I don't think 2) will succeed.
>
> -----Original Message-----
> From: Daniel Fink [mailto:Daniel.Fink_at_Sun.COM]
> Sent: Wednesday, March 17, 2004 5:38 PM
> To: oracle-l_at_freelists.org
> Subject: Transportable Tablespace, SCNs and ORA-1555s.
>
> This is not in response to an actual problem, it is just the
> result of a brain that goes off on tangents way to often...
>
> How does a transaction know NOT to build a consistent version of
> data that has been transported?
>
> Sequence of events
> 1) Insert records into table1. A Commit SCN of 100000 is
> assigned. Due to the size of the insert, there are blocks in the
> table that still have an Uncommitted state.
> 2) Alter tablespace1 (containing table1) to read only and
> transport it to database2.
> 3) Start a query in database2 (with an SCN of 1000) that
> accesses the newly transported table1.
>
> Will the query get a 1555?
>
> Yes - It cannot create a read consistent view to SCN 1000
> No - It knows that this data came from another database, so it
> does not attempt to build a read-consistent version
>
> Thoughts on which is correct? I know, I know...build a damn
> testcase and see for myself. I'm working on it, but I wanted to
> see what you all thought first.
>
> Daniel
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Wed Mar 17 2004 - 20:34:01 CST
 |
 |