oracle backup is hanging up on one datafile

[Thierry Poels_1]

hi,

- does an "lvdisplay -v" for this logical volume report any stale extents?
- after a DB shutdown you can try a dbverify on this datafile.
- the datafile did not reach 2GB without having largefiles option set?

regards,
Thierry.

[T G Manikandan]

I would suggest to check the alertlog for that database.

Also query your V$log as whether they are active.

REvert

[Ashraf_1]

Hi,

I enabled largefile on this volume with the necessary mount point then tried the command cat on this file.
Unfurtanately, it is still having the problem and even though the process can't be killed the only way is to restart the system.

lvdisplay -v for this volume is not showing in stale extents status.
I couldn't find the command dbverify (note our oracle is 7.3.4 on hp-ux 11i).
The output of v$log is showing below:

SVRMGR> select * from v$log
2> ;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHAN FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ---------- --------------------
1 1 48006 20971520 2 NO CURRENT 99394873 12/08/03 08:36:49
2 1 48003 20971520 2 YES INACTIVE 99394236 12/07/03 08:41:35
3 1 48005 20971520 2 YES INACTIVE 99394805 12/07/03 10:26:23
4 1 48004 20971520 2 YES INACTIVE 99394711 12/07/03 10:18:27
4 rows selected.

The output of database alert log is showing below:



Attached is my mail outupt after running the command cat..

FYI, the data file size of this file is 1992302592 and we are using oracle 7.3.4 on hp-ux 11i.

Regards,
Ashraf

[Alexander M. Ermes]

Hi there.
Just a hint :

Certify - Certification Matrix: Oracle Database - Standard Edition on HP-UX PA-RISC

--------------------------------------------------------------------------------


Server Certifications
OS Product Certified With Version Status Addtl. Info. Components Other
11i 7.3.4 N/A N/A Desupported Yes None N/A
11.0 7.3.4 N/A N/A Desupported Yes None N/A
10.20 7.3.4 N/A N/A Desupported Yes None N/A




--------------------------------------------------------------------------------
Your attached file shows some hardware problems. Try to contact HP support for more intense analysis. Did you try the dmesg ?
Have you checked the syslog files ?

For the locked file : have you tried the lsof statement ?
Download address :

http://hpux.connect.org.uk/

Perhaps a process is still locking it.

By the way :
Your database version is not certified with the OS version.
Try to upgrade the databse at least to 8.1.7.4 .
Rgds
Alexander M. Ermes

[Hein van den Heuvel]

The Event Monitor log attached to the prior reply is pretty clear about a hardware error notably on:
Logical Block Address............: 29945632 (0x01C8EF20)
Transfer Length..................: 16 (0x0010).
You mission, should you accept it, is to map the LBA back to a file offset through filesystem mapping pointers.

So you should restore a backup, and apply the archives!


The other replies suggests that Oracle has not yet complained about that error.
The backup might be asked to read blocks that are not yes used by Oracle for data storage. For grins you could dump (with help of dd and iseek), and see if is is all zeroes.
If you are very adventureous, or very desperate, and pretty smart (or have smart friends :-), then you may be able to make a clean copy of this file before Oracle runs into the trouble spot. Possible approaches include:
- have oracle create a similar (size!) tablespace, detach that from oracle (drop tablespace). save controlfile to trace. Stop db, copy broken file over empty/unused tablespace (will get an error. ignore), rename file, re-start db with create controlfile....
- yes you can easily make matters worse!
- if you are very lucky (in this bad-luck situation), you can also try to write data (zeroes!) to the broken space and the disk will re-vector the bad blocks transparently. Of course there is no telling how much data is unreadable at this time.

Best get those backups restored!
Good luck,
Hein.

[twang]

The Event Monitor log indicates it was caused by a harddisk problem. I would suggest to carry out a dd test on the problem disk:
# dd if=/dev/rdsk/c?t?d? of=/dev/null bs=2048k