Conference turris::digital_unix

8724.0. "ORACLE FILE "SHRINKS" AFTER ELECTRICAL POWER OFF" by IB001::ANAMARIA (Ana Garc�a, MCS (Madrid)) Wed Feb 05 1997 09:45

	Hi all.

	My customer has had a problem with her Oracle database. There was a 
    sudden electric power off and when the system could boot, one of the Oracle 
    log files shrinked from 513024 bytes to 335872 bytes. Due to this reason, 
    Oracle couldn't start because it complained expecting 513024 bytes and 
    founding 335872 bytes instead.

	The customer asked Oracle about this problem and Oracle said that it 
    was an operating system problem, that they have a similar problem reported
    being solved through an operating system command that changed the 
    blocks allocated to a file in the file header.

	First of all, I thought that the problem could be something relationed 
    to sparse or zero-filled files, but Oracle told the customer that Oracle 
    database creates zero-filled files, and the customer file was zero-filled:

	#ls -ls
	336  ........    335872 ........... /oracle/dbs/log_file


	After looking for a lot of information and without finding anything 
    relationed to this problem, I contacted directly to Oracle and told me that 
    the problem reported was with LINUX and not Digital UNIX, and that they 
    had no more information about the solution because it was not Oracle fault.

	I began to look for some tool to change a file metadata but I didn't 
    find anything in ADVfs (the customer damaged file is on Advfs). However, I 
    found the 'fsdb' command (that only works with ufs) and began to test. In 
    order to try to solve the problem, I told the customer to copy the file to 
    an ufs filesystem, change the 'sz' field to the expected figure, through 
    the 'fsdb' command and copy back the file to the original advfs filesystem.

	The customer has done the test and now Oracle doesn't complain about 
    the size, but there are other problems about the data consistency.

	My customer, and me too, think that it's an Oracle problem, but I 
    would like to confirm some things:

	1.- Has anybody found a similar behavour (a file losing blocks after 
    an electric power off) with and without ORACLE?. I'd like, if possible, an 
    official answer from Digital saying that it's not an operating system
    problem, in order my customer to report the problem in Oracle. 

	2.- Is there in Advfs a similar command to 'fsdb'?.

	3. About the 'fsdb' command, I thought that changing the 'sz' field, 
    the 'bytes occupied' value in the 'ls' listing would change to the new 
    quantity, but it was not modified; the listing is exactly the same as 
    before the change. But there has been some change (although I don't know 
    where) because Oracle has recognized it.

	The Digital UNIX version is 3.2D-1.

	Any help for the questions above, specially the first one, will be 
very appreciated.

	Thanks in advance.

	Regards.

					Ana
    

    In answer to your first question - I've only seen this happen if DECnsr
    was used for backup and the file was restored from there. Older
    versions of DECnsr would strip out blocks of zeros in files. I haven't
    seen this happen with files on-line under AdvFS.
    
    For question 2 - the answer is no, there isn't anything like fsdb for
    AdvFS.
    
    For question 3 - I'm just guessing here, but if Oracle uses stat() to
    check the size and that's what sz changes, then it could have made
    Oracle pass the size check. But as you said there are other problems
    with data consistency, so just having the size match doesn't mean the
    file is going to be correct. I would guess this is an Oracle problem,
    unless the customer did something that they aren't telling you about.

We had a similar problem last year, reported to us twice by two different
customers.  Only it wasn't the Oracle log file that was shrinking, it was
one of the Oracle binaries that was being corrupted.  Again, it only ever
happened when the system accidentally suffered a power failure and it was
reproducable. In both cases the underlying f/s was AdvFS and the problem
was resolved (if I remember right) by catching up on the latest AdvFS
patches, or upgrading to a later release.

I can't remember what version of d-unix these problems occured on though.

John
------------------------------------------------------------------------------

Email: [email protected]                            John McNulty
Tel: (44) 1256 373862                            UK CSC, Unix Support Group
DTN: 833-3862                                    Digital Equipment Corporation

[Posted by WWW Notes gateway]

    	Hi.
    
    	Thanks to .1 and .2 for your answers.
    
    	Regards.
    
    				Ana