Skip to Main Content
  • Questions
  • Error ora-01640 making tablespace read only without active transaction

Breadcrumb

Question and Answer

Chris Saxon

Thanks for the question, Balu.

Asked: July 31, 2017 - 9:44 am UTC

Last updated: August 01, 2017 - 3:13 pm UTC

Version: oracle 10g

Viewed 1000+ times

You Asked

Hi Tom,
We are trying put a tablespace into readonly mode and getting error ora-01640.
There is no transaction as the database was stopped and started in normal mode..
Only one session was established from which table space readonly was executed.
--
ERROR at line 1:
ORA-01640: cannot make tablespace read only with active transactions
----

and Chris said...

By any chance is your compatible parameter set to lower than 8.1 (!)?

As MOS note 33402.1 states:

You do not have to wait for transactions to complete before issuing the
ALTER TABLESPACE...READ ONLY statement. When the statement is issued,
the target tablespace goes into a transitional read-only mode in which no further
DML statements are allowed, though existing transactions that modified the
tablespace will be allowed to commit or rollback. Once this occurs, the
tablespace is quiesced, with respect to active transactions.

Note: This transitional read-only state only occurs if the value of the
initialization parameter COMPATIBLE is 8.1.0 or greater. For parameter
values less than 8.1.0, the ALTER TABLESPACE...READ ONLY statement fails
if any active transactions exist.


If I have an uncommitted insert to a table in session 1:

create tablespace tbsp datafile 'tbsp.dbf' size 1M;

create table t (
  x int 
) tablespace tbsp;

insert into t values (1);


and session 2 I try and make corresponding tablespace read only, it is blocked:

alter tablespace tbsp read only;


Until I commit/rollback the insert.

You can check for open transactions by querying v$transaction. You can use this to identify those that may be stopping you making it read only. From MOS note 33402.1 again

If you find it is taking a long time for the tablespace to quiesce, it is possible to 
identify the transactions which are preventing the read-only state from taking effect. 
The owners of these transactions can be notified and a decision can be made to 
terminate the transactions, if necessary.  The following example illustrates how you 
might identify the blocking transactions. 

Identify the transaction entry for the ALTER TABLESPACE...READ ONLY statement. 

SELECT sql_text, saddr 
     FROM v$sqlarea,v$session
    WHERE v$sqlarea.address = v$session.sql_address    
      AND sql_text like 'alter tablespace%'; 

SQL_TEXT                                   SADDR   
----------------------------------------   --------
alter tablespace tbs1 read only            80034AF0

The start SCN of each active transaction is stored in the V$TRANSACTION view.
Displaying this view sorted by ascending start SCN lists the transactions in 
execution order.  Knowing the transaction entry for the read-only statement, it 
can be located in the V$TRANSACTION view.  All transactions with lesser or 
equal start SCN can potentially hold up the quiesce and subsequent read-only
state of the tablespace. 

SELECT ses_addr, start_scnb 
     FROM v$transaction
    ORDER BY start_scnb;

SES_ADDR START_SCNB
-------- ----------
800352A0       3621   --> waiting on this txn
80035A50       3623   --> waiting on this txn
80034AF0       3628   --> this is the ALTER TABLESPACE statement
80037910       3629   --> don't care about this txn


If this doesn't help, please give us more details about what you're doing that includes the exact statement that is leading to your error. And ideally a complete test case (including create table, tablespace, etc.) we can copy to reproduce the problem.

Rating

  (4 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Balu Subramainan, July 31, 2017 - 10:24 am UTC

Hi Tom,
we checked the compatible parameter and is greater the 8.1
Also we checked the v$transaction table but not able to find any transaction(table is empty)

Even stopped listener to ensure external process establish a session
Created a new undo segment table space and that also not able to read only mode

We are able to put whole database into readonly but not the table space
It is very critical for us
---

We found the similiar error was reported in oracle community and no answered

https://support.oracle.com/epmos/faces/CommunityDisplay?resultUrl=https%3A%2F%2Fcommunity.oracle.com%2Fthread%2F2831454&_afrLoop=184579542865620&resultTitle=Transportable+Tablespace+errors+out.&commId=2831454&displayIndex=1&_afrWindowMode=0&_adf.ctrl-state=103d152si7_131

Balu Subramainan, July 31, 2017 - 12:36 pm UTC

Hi Tom,
a) The compatibility parameter is set greater than 8.1
b) No transaction/session excluding the user who involved the read only command
c) Listener was down so than external process will not create a session
d) We executed the below query and found 13 rows of stranded transaction
SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */ KTUXESTA Status,KTUXECFL Flags
FROM x$ktuxe WHERE ktuxesta!='INACTIVE'; 2

KTUXEUSN KTUXESLT KTUXESQN STATUS FLAGS
---------- ---------- ---------- ---------------- ------------------------
1 18 85277 PREPARED SCO|COL|REV|DEAD|EXTDTX
2 22 130991 PREPARED SCO|COL|REV|DEAD|EXTDTX
5 24 82474 PREPARED SCO|COL|REV|DEAD|EXTDTX
10 38 99382 PREPARED SCO|COL|REV|DEAD|EXTDTX
11 42 100147 PREPARED SCO|COL|REV|DEAD|EXTDTX
12 26 7456 PREPARED SCO|COL|REV|DEAD|EXTDTX
13 14 6009 PREPARED SCO|COL|REV|DEAD|EXTDTX
14 28 61568 PREPARED SCO|COL|REV|DEAD|EXTDTX
16 2 59566 PREPARED SCO|COL|REV|DEAD|EXTDTX
18 35 56733 PREPARED SCO|COL|REV|DEAD|EXTDTX
23 29 62698 PREPARED SCO|COL|REV|DEAD|EXTDTX

KTUXEUSN KTUXESLT KTUXESQN STATUS FLAGS
---------- ---------- ---------- ---------------- ------------------------
32 18 9172 PREPARED SCO|COL|REV|DEAD|EXTDTX
f) Checked the rollstat status
SELECT a.name,b.status FROM v$rollname a,v$rollstat b WHERE a.usn = b.usn AND a.name IN (SELECT segment_name FROM dba_segments WHERE tablespace_name = 'UNDOTBS1');

NAME STATUS
------------------------------ ---------------
_SYSSMU1$ PENDING OFFLINE
_SYSSMU2$ PENDING OFFLINE
_SYSSMU5$ PENDING OFFLINE
_SYSSMU10$ PENDING OFFLINE

Could you please help us in resolving the issue
Chris Saxon
July 31, 2017 - 4:55 pm UTC

By any chance have you changed the undo tablespace for the database? See MOS note 341372.1 for details.

Can you restart the database? Does that help?

Balu Subramainan, July 31, 2017 - 7:13 pm UTC

Thanks Tom for your support.,
We restarted the database. It is not working.
Looks like rollback segment have corruption

SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */ KTUXESTA Status,KTUXECFL Flags
FROM x$ktuxe where ktuxesta!='INACTIVE' and ktuxeusn in (select segment_id from dba_rollback_segs where status='PARTLY AVAILABLE'); 2

KTUXEUSN KTUXESLT KTUXESQN STATUS FLAGS
---------- ---------- ---------- ---------------- ------------------------
14 28 61568 PREPARED SCO|COL|REV|DEAD|EXTDTX
16 2 59566 PREPARED SCO|COL|REV|DEAD|EXTDTX
18 35 56733 PREPARED SCO|COL|REV|DEAD|EXTDTX
23 29 62698 PREPARED SCO|COL|REV|DEAD|EXTDTX
32 18 9172 PREPARED SCO|COL|REV|DEAD|EXTDTX

select segment_id ,status from dba_rollback_segs where segment_id in (
SELECT KTUXEUSN
FROM x$ktuxe where ktuxesta!='INACTIVE' ) 2 3
4 ;

SEGMENT_ID STATUS
---------- ----------------
1 ONLINE
2 ONLINE
5 ONLINE
10 ONLINE
11 ONLINE
12 ONLINE
13 ONLINE
14 PARTLY AVAILABLE
16 PARTLY AVAILABLE
18 PARTLY AVAILABLE
23 PARTLY AVAILABLE

SEGMENT_ID STATUS
---------- ----------------
32 PARTLY AVAILABLE

How to remove this rollback segment



Chris Saxon
August 01, 2017 - 2:08 pm UTC

The database still thinks you have active transactions for some reason. I think it's time for you to call support!

Balu Subramainan, August 01, 2017 - 2:21 pm UTC

Today we spoke to oracle support and they provide the necessary steps
Chris Saxon
August 01, 2017 - 3:13 pm UTC

Great. Care to share with us?

More to Explore

Administration

Need more information on Administration? Check out the Administrators guide for the Oracle Database