RE: Transportable Tablespace, SCNs and ORA-1555s.

  • From: "Richard Ji" <Richard.Ji@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 17 Mar 2004 18:05:17 -0500

My understanding is that you can issue the alter tablespace ... read only
without have to wait for transactions to complete.  But existing transactions
need to be either commit or rollback before the tablespace can be quiesced.

-----Original Message-----
From: Daniel Fink [mailto:Daniel.Fink@xxxxxxx]
Sent: Wednesday, March 17, 2004 5:50 PM
To: oracle-l@xxxxxxxxxxxxx
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@xxxxxxx]
> Sent: Wednesday, March 17, 2004 5:38 PM
> To: oracle-l@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //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@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: