I bet your database files are not upgraded to 8.1.7.0.
I can't get how you could open the DB from one or another release without errors. I wonder that since this is a patch release upgrade (http://docs.oracle.com/cd/A84870_01/doc/server.816/a76957/migintro.htm#10138), and the COMPATIBLE
parameter in init file its in 8.1.5, when you start the DB from 8.1.7 it builds compatible memory and disk structures with 8.1.5 version and "works" (at least, it opens. But I wouldnt go with this even in TEST environment)
To check the DB version You can also use the DBMS_UTILITY.DB_VERSION procedure. I don't know if it will return the instance or the database files version. You can run something like this in sqlplus:
SQL> set serveroutput on
SQL> DECLARE
v_version varchar2(10);
v_comp varchar2(10);
BEGIN
DBMS_UTILITY.DB_VERSION ( v_version, v_comp);
DBMS_OUTPUT.PUT_LINE ('DB Version: ' || v_version);
DBMS_OUTPUT.PUT_LINE ('Compatibility: ' || v_comp);
END;
/
Another option is the hardway. In linux if I use strings
with my SYSTEM TABLESPACE datafile I can grep
the release version from them. But ... I cannot claim this is a reliable method :\
$ strings o1_mf_system_91ck66x1_.dbf | grep "[0-9]\{1,2\}\.[0-9]\{1\}" | grep -i "Catalog Views" | head
Oracle Database Catalog Views Re Oracle XML Database Version 11.2
COracle Database Catalog Views Release 11.2.0.3.0 - 64bit Production"DBMS_REGISTRY_SYS.VALIDATE_CATALOG
COracle Database Catalog Views Release 11.2.0.3.0 - 64bit Production"DBMS_REGISTRY_SYS.VALIDATE_CATALOG
COracle Database Catalog Views Release 11.2.0.3.0 - 64bit Production"DBMS_REGISTRY_SYS.VALIDATE_CATALOG
Anyway, In a mess like this I'll go for export-import migration, and forget about what has been done in the past. You said you can perform export with no problems, right? If the database its now open with 8.1.5, and the application has been hard tested with no errors, let's assume it's on 8.1.5 and migrate. Perform a new fresh 8.1.7 install, stop the application, export every application related schema from the production DB, and import into the new 8.1.7. Done.
Now, me and everyone will tell you that this is ridiculous. Why this? I'll try to migrate to a new server and DB version at any cost precisely because the elderly nature of your environment will make it only harder and harder in the future, not to mention the lack of security and new features of having a 13 years old software release running in a server powerless that your cellphone.
I cant imagine a good reason to not migrate that server entirely, even more when (based on what you said) no one knows what kind of mess did in the past.
Fix the problem, not the symptom =)
Regards
Best Answer
We got to the bottom of this eventually!
It was an oracle group write (g+w) permission missing in the parent folder of the diagnostic_dest structure. Why it gives an error 443 and not a simple write permission error, only the oracle engineers who created this enigmatic diagnostic_dest structure will know!