RESIZE datafile bug???

I've just been hit by a weird problem in one of my test instances ... maybe someone else has come across this, and found a fix for it

1. Oracle 7.2.2.4 on Sun Solaris 2.5.1, NOARCHIVELOG mode
2. SeveraL days ago I issued an alter database datafile '/oracle/db02/tools.001' resize 10M because it was created at 30M, and we were never going to load anything into it. Datafile worked fine ... could create, drop objects, and coalesce the free space without problem.
3. Today, in testing for a machine migration, we plugged all the drives into the new cpu. ORACLE started up fine, and all database objects could be manipulated.
4. Later, because we will be restriping the data files, I decided to use my usual method ...
5. alter database backup controlfile to trace
6. edit the control file backup to reflect the new spindle locations
7. shutdown the database, move the various datafiles, and do some necessary filename renaming in the init.ora file
8. wipe out the existing control files, and in sql*dba:
   • run the edited trace file to recreate the database using the new filenames.

During creation of the new control file, ORACLE aborted saying that the file I had resized several days ago was only 10M, while it should be 30M, and then aborted the startup. It will not create the control file, so I can't get as far as startup mount, in order to drop the datafile.

This is actually a potentially serious issue, as it implies (unless I've missed something obvious), that one can't recreate a database from a backup control file if any data files have been resized.

I know that I have many other ways that I can accomplish the same end result, including export and import to a new database, but I am concerned if the backup controlfile mechanism is concerned.

This happened rather late today, but I will be contacting ORACLE tomorrow to open a TAR, but I am hoping in the interim that maybe someone will already know how to fix this problem.

This is NOT serious to me in terms of affecting an instance that anybody cares about, but it does seem important to resolve, to feel sure that database recoveries will work in all cases.

Bill

-- 


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

E-Mail: Beatonb_at_cadvision.com or Bill_Beaton_at_calgary.qc-data.com


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