1 Reply Latest reply on Dec 6, 2012 11:43 AM by Srini Chavali-Oracle

    DBUA issue with timezones when upgrading to

      My task is to migrate an Oracle test database (source database) to The source database hat timezone files (RDBMS DST) version 18 installed. OS ist Windows 2008 R2.

      I installed the patchset into a separate Oracle Home (target) to perform an "Out-of-place"-upgrade. According to Note 1358166.1 I also installed the corresponding timezone files (version 18) into the target Oracle Home by applying the corresponding patch set using Opatch. The patch succeeded, and new files were copied into the \oracore\zoneinfo subdirectory under the target's Oracle Home. The files included a file named "readme_18.txt". As there is no database under the target Oracle Home there is no way to do the rest of the installation steps as described in Note 977512.1 (i.e. DBMS_DST.UPGRADE_DATABASE)

      When I started the DBUA GUI from the Windows Start Menu (the version from the target Oracle Home), the source database was found, however during the analysis phase I got an error message stating that the timezone files on the target database have a lower version that the timezone files of the source database. The error in the trace.log (subdirectory of ORACLE_BASE\cfgtoollogs\dbua) reads:

      *[PreMigrationCheck.checkTZVersion:101] new oracle home TZ file version 14 and source oracle home TZ file version 18*

      To ensure that this problem is not resolved with one of the patchsets, I deinstalled the targed Oracle Home, reinstalled the release, applied the latest patchset (Patch 13) using OPatch and then applied the timezone files version 18 using OPatch: Same error as before.

      I started reading tons of documents, but I found nothing about this error in the forum or other places in the internet. So I started experimenting and I found a workaround: In the \oracore\zoneinfo subdirectory I renamed
      - readme.txt to readme_14.txt and
      - readme_18.txt to readme.txt

      When I started DBUA again, the error did not return and I was able to migrate.

      Question: Did I use a suitable workaround, or is there a better way to circumvent the DBUA error? Maybe I missed an important step.