database migration failure

[Dave Chamberlin]

Hello,
I was attempting to migrate my production database from 7.3.4 to 8i. I have performed this several times on two other servers, on instances cloned from the production system. The only difference in the instances - is that the production server has log archiving enabled. For the migration, the initORA file had been changed - setting LOG_ARCHIVE_START = FALSE before starting the procedure.
The migprep program was hung at one point and the alert log indicated that log files needed archiving - I had to enable logging with a svrmgrl session to get it past that point. The migprep program aborted at the last line - (could do an alter database close) due to the svrmgrl session still connected - though the conv.dbf file WAS created in the dbs directory. On issuing the "alter database convert" command, this error was returned:
ORA-27072 skgfdisp: I/O error
additional information: 43


On consulting the errno.h file for this error - it reads that "the error numbers between 37 and 44 are not produced by HPUX".

Has anyone else ever seen this problem? Also - why did the logs need archiving when the archving was set to FALSE in in the initORA file?

[John Palmer]

Hi,

The logs needed archiving because setting LOG_ARCHIVE_START = FALSE simply tells the database not to automatically start the ARCH process which does the archiving. This means that you'd have to archive manually (which you did).

What you probably meant to do was put the database in NOARCHIVELOG mode to prevent redo logs having to be archived at all. That's done with svrmgrl (or sqlplus internal) with the database closed...
startup mount;
alter database noarchivelog;
alter dtabase open
exit

Regards,
John

[Stan_17]

Hi,

Other poster John had given you enough information as to why logs needs archiving though you had l_a_s = false.

Regarding "ORA-27072 skgfdisp: I/O error" -- did you check alert.log file for details of the error message, that should be a good starting point.

Stan

[Dave Chamberlin]

Hi Stan,

Unfortunately, the alertPROD.ora file gives no details - just :ORA 27072 signalled during: alter database convert

[Brian Crabtree]

You will most likely want to restore your database, and redo the migration. One possiblity, depending on your database size, would be to perform an export, and import into a new database, rather than migrating it.

Brian

[Steven E. Protter]

Restore the database.

metalink reports your error with regards to the 2 Gig file limit.

It is possible that your database will get bigger when you migrate it. Are the filesystems its sitting on largefiles enabled?

I'd restore, check into that issue and try again when the issue is addressed.

SEP

[Indira Aramandla]

Hi Dave,

When you are migrating an Oracle 7.3.4 DB to 8i and if the database is runing in ARCHIVELOG mode then ensure that the archiver is started automatically otherwise the migrate may stall waiting to archive the online logs. Set LOG_ARCHIVE_START to TRUE and ensure the archive destination has plenty of free space. This is one of the preparation steps for migration procedure oracle mentions in the check-list for migration (Note:76460.1- Metalink).

Now to fix your database problem, depends on howfar have you gone with the migration. If the migration path is before the "ALTER DATABASE CONVERT" then there are chances at this point you could still open your database using Oracle7 code.
to continue. If you do open the database using Oracle7 then note that:
a)You will need to re-run the Oracle7 catalog and catproc if you want to use the database under Oracle7.

But remember even a simple startup / shutdown will mean you have to re-run the above migration steps again otherwise the "convert" file will then contain invalid checkpoint information.

If your migration path is beyond the ALTER DATABASE CONVERT statement then it requires you to revert to a backup, restore the DB and then follow the migration procedure again.

If you have a good backup I would prefer to restore from backup, and then follow the migration procedure again. Make sure the automatic archive = TRUE if your DB is runing on archivelog mode, and have plenty of space in the archivelogs file system.

[Printaporn_1]

Hi,

Please check your archive destination.
It may not goto the right place ?
permission ? file system full ?

[Dave Chamberlin]

Thanks for the replies. I was able to reproduce the problem by running archive mode on a test instance and running the same procedure. I found that the extra session that I used to enable archiving - caused a truncation of the convSID.dbf file, and that caused the ORA-27072 failure. I tried again, and turning off the archiving prior to the start of the migration process insured completion of the mig command and the convDIS.dbf was correct. then converts ok. I never did get an answer from Oracle on the the "additional information: 43".
Thanks