Peter, The subject is too big for anyone. But 99% of the time, the real problem comes down to common sense. In your case, it's file access, or corruption: ORA-00376: file 1 cannot be read at this time ORA-01110: data file 1: '/u01/app/oracle/oradata/BABYDB/datafile/o1_mf_system_45xrz1n7_.dbf' If it tries a few times and works, you need to work with the storage or SA team to check the filesystem. > c. How do u enumerate all the "LIBRARY OBJECT"? And specifically > for this one: > > LIBRARY OBJECT: object=2377171c > type=TABL flags=EXS/LOC[0005] pflags=[0000] status=VALD load=0 Dump library cache or query x$kglob to enumerate all. I think the number 2377171c uniquely identifies the library cache object. You can find its details in x$kglob matching kglhdobj with '2377171C' (uppercase "C"!). This object is a table in data dictionary and it exists. No load lock. Not sure about the flag. > d. Decipher the following - which pertained to the above object: > > DATA BLOCKS: > data# heap pointer status pins change whr > ----- -------- -------- --------- ---- ------ --- > 0 23778100 237717d8 I/P/A/-/- 0 NONE 00 > 8 2377193c 237711a0 I/P/A/-/- 0 NONE 00 > 9 23771a18 0 I/-/-/-/- 0 NONE 0c All objects have heap 0. Cursors have 0 and 6. PL/SQL can have 2 and 4. I guess tables and views can have 8 and 9. I/P/A may be initialized, pinned, allocated. > e. What lwt, pwt, ltm, ptm, and ref/ind? I don't know. > f. What is FOB? The abbreviation FOB appears in various places, such as "Synchronizes various File Object(FOB) operations" in v$lock_type for FP lock. What follows it is detailed info about the file as appeared in the library cache. This kind of analysis is unlikely needed for solving a problem. But for curiosity, you can take a look at my notes I keep updating over the years: http://yong321.freeshell.org/oranotes/processstatedumpnotes.txt Yong Huang -- //www.freelists.org/webpage/oracle-l