We have this QA database which I can mostly ignore but Mr. QA dude found a bug caused by the compatible init.ora parameter not being properly set. Since they kind of admin their own database and know the timing of their database availability needs for QA testing, I gave QA dude instructions on recycling the database... "SQL> shutdown abort" and "SQL> startup"=20 But the database didn't come back up due to a shared memory error so I figured I'd have to fix things with ipcs/ipcrm. But before getting into that I just tried "SQL> startup" myself and behold, everything started up just fine with no warning messages or anything. Hmmm... That's curious... I guess the oracle just likes me better. I was in $ORACLE_HOME/dbs verifying the existence of the "lk$ORACLE_SID" file when I saw something curious... A 100MB file named "MISSING00042" which had the same database startup timestamp as the lk$ORACLE_SID file and wondered what it was and where it came from. So I queried dba_data_files and the data file with file_id 42 has the path of $ORACLE_HOME/dbs/MISSING00042. Whoa!!! That directory path and 100MB are the default values when using Oracle-managed files and 42 is the answer to all things! But we don't use Oracle-managed files. Curious but how could the oracle create this datafile automagically for me and not even tell me? Where's it going to get the data? Then I look at dba_segments and see that there's only one object in that tablespace/datafile, an index which could be rebuilt from the data in another tablespace the table is in. Does this mean that the oracle couldn't find the datafile but created it for me automagically just because it could and because the only object was an index?=20 Has anybody seen this behavior before? Is there any documentation on it? Running Oracle 9.2.0.4 on Linux. Steve Orr Curious in Bozeman, Montana ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------