RE: Strange problem

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <gogala.mladen@xxxxxxxxx>, "'oracle-l'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Sun, 30 Apr 2017 23:35:46 -0400

Two cases I have seen too old for me to remember the exact error numbers, but 
with similar symptoms working on restart and then intermittently not working:


1)    A file that has autoextended past the addressable length and an extent 
past the addressable length is trying to be flushed by dbwr. But I *thought* 
they fixed that circa V10 so that even if the beginning of a file’s next 
autoextend was within range but the size of the extension would put it past the 
addressable size it would either refuse to extend to only extend to the maximum 
addressable length. You might be able to decode the data block addresses to see.

2)    A particular type of removable drive unfortunately had pegs sticking into 
a narrow aisle such that someone walking down the aisle could bump them and put 
a that drive into a read only state at the hardware level.


#1 was slimy because the file would read at start time (apparently the 
addressing for the tail block was in a bigger address space than dbwr used at 
the time.) IF memory serves we were lucky and the extent was an index, so we 
were able to drop that index and fill the tablespace with dummy tables until we 
were sure all the space not actually writable would never be written until we 
had time to move everything out of that table space.


#2 would have been hilarious if it had not been so difficult to diagnose, and 
resulted in a customer added cardboard flange protecting the buttons.


It’s probably something completely different, but I think it IS likely that 
dbw0 is somehow losing write authority. IF this were RAC a wild guess would be 
instances started by different owners and the one trying to write doesn’t have 
the right owner and/or group authority.




From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mladen Gogala
Sent: Sunday, April 30, 2017 4:22 PM
To: oracle-l
Subject: Strange problem



I am having a strange problem with an Oracle instance on SUN Solaris 
11.3 (SPARC):

ORA-01110: data file 7: '/oradata/DEV/datafiles/data01b.dbf'
2017-04-28 23:05:11.723000 -04:00
Flush retried for xcb 0x5c0e98a90, pmd 0x5c3faa538
Errors in file /app/oradev/diag/rdbms/oradev/DEV/trace/DEV_pmon_465049.trc:
ORA-00372: file 7 cannot be modified at this time
ORA-01110: data file 7: '/oradata/DEV/datafiles/data01b.dbf'
2017-04-28 23:05:18.756000 -04:00
Flush retried for xcb 0x5c0e98a90, pmd 0x5c3faa538
Errors in file /app/oradev/diag/rdbms/oradev/DEV/trace/DEV_dbw0_465083.trc:
ORA-00372: file 7 cannot be modified at this time
ORA-01110: data file 7: '/oradata/DEV/datafiles/data01b.dbf'
USER (ospid: 465083): terminating the instance due to error 372
System state dump requested by (instance=1, osid=4295432379 (DBW0)), 
summary=[abnormal instance termination].
System State dumped to trace file 
2017-04-28 23:05:23.820000 -04:00
Instance terminated by USER, pid = 465083
2017-04-29 10:58:13.293000 -04:00
Starting ORACLE instance (normal) (OS id: 44563)
CLI notifier numLatches:29 maxDescs:1355
All SGA segments were allocated at startup

When I restart the instance all files are available. The instance is patched 
with the January 2017 PSU, soon to be patched with April 2017 PSU. Here are the 
relevant versions:

SunOS sun02 5.11 11.3 sun4v sparc sun4v
-bash-4.4$ sqlplus / as sysdba
SQL*Plus: Release Production on Sun Apr 30 16:15:43 2017
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing 

The underlying file system is, of course, ZFS. When the instance is restarted, 
all the files are available and there is nothing in the V$RECOVER_FILE. I 
opened SR with Oracle, but as this is a development system, they are taking 
their time. Has anyone seen this before and, if yes, what would be the 
solution? The system crashes during nightly batches, which load a lot of data 
and are write intensive.





Mladen Gogala
Oracle DBA
Tel: (347) 321-1217

Other related posts: