Re: Datafile mistery...

From: -={Giorgio}=- <leva.md3496_at_mclink.it>
Date: Wed, 13 Aug 2003 00:50:04 +0200
Message-ID: <bhbqn5$19dd$1@newsreader2.mclink.it>

[...]
> Somebody out there will now post a reply about dd or somesuch wonderful
> Unix/Linux command that stuffs the inodes. But your other alternative is
> just to imagine that the loss of the datafile has caused an instance
> crash, and throw in a shutdown abort as part of your testing.

Well ok... fair enough i think...
but i am quite stubborn :)

$ lsof | grep ctrl_

oracle    27607 oracle   /u02/oradata/topo/ctrl_topo01.ctl
oracle    27607 oracle   /u03/oradata/topo/ctrl_topo02.ctl
oracle    27609 oracle   /u02/oradata/topo/ctrl_topo01.ctl
oracle    27609 oracle   /u03/oradata/topo/ctrl_topo02.ctl
oracle    27611 oracle   /u02/oradata/topo/ctrl_topo01.ctl
oracle    27611 oracle   /u03/oradata/topo/ctrl_topo02.ctl

this is more or less what i get from an lsof (list open file) under linux... three processes access the control file (lgwr,dbw0 and ckpt)

now this is the second output after i removed one of the controfile

$ lsof | grep ctrl_

oracle    27607 oracle   /u02/oradata/topo/ctrl_topo01.ctl (deleted)
oracle    27607 oracle   /u03/oradata/topo/ctrl_topo02.ctl
oracle    27609 oracle   /u02/oradata/topo/ctrl_topo01.ctl (deleted)
oracle    27609 oracle   /u03/oradata/topo/ctrl_topo02.ctl
oracle    27611 oracle   /u02/oradata/topo/ctrl_topo01.ctl (deleted)
oracle    27611 oracle   /u03/oradata/topo/ctrl_topo02.ctl

perfect (deleted) is part of the lsof output... let's go on...

(blah blah)

SQL> shutdown immediate

ORA-00210: cannot open the specified controlfile
ORA-00202: controlfile: '/u02/oradata/topo/ctrl_topo01.ctl'
ORA-27041: unable to open file

Linux Error: 2: No such file or directory Additional information: 3

Oops...
now we have a different behaviour

previously i removed a datafile and:

a) db shutdown correctly
b) db startedup correctly
c) access to the datafile failed as soon as the server needed to get

data from it

...but now we have that the database doesn't even shutdown properly.

The absurd reason is that O do not even try to access the datafile as long as it doesn't need to (no transaction as long as O has the data on the redo log not yet overwritten, not even in shutdown and startup), when in the case of the ctrlfile O must flush information at db shutdown and here we are the denied access to the ctrlfile even if the inode is still allocated.
The other (not very absurd) reason is that another O process is trying to access the control file and the other process should be one among PMON, SMON and RECO (the three left since the other three still access the deleted file).

Dunno the internal shit (other than what official docs say) that O does during SUp or SDown... I am wondering if it's more related to the file system I am using (ext3)

/G Received on Tue Aug 12 2003 - 17:50:04 CDT