[Translated from mos] When the asm disk is specified as FRA, The dbua hang of 11.2.0.3 stays at 11.2.0.3dbua.

[Translated from mos] When the asm disk is specified as FRA, The dbua hang of 11.2.0.3 stays at 11.2.0.3dbua.

When the asm disk is specified as FRA, The dbua hang of 11.2.0.3 stays

Source:
11.2.0.3 DBUA Hangs While Specifying ASM Disk To FRA (Document ID 1427179.1)

Applicable:
Oracle Database Upgrade Assistant-Version 10.2.0.1 and later
Oracle Server-Standard Edition-Version 10.2.0.1 and later
Oracle Server-Enterprise Edition-Version 10.2.0.1 and later
Information in this document applies to any platform.

Symptoms:
DBUA hangs if ASM disk is specified to FRA (Fast Recovery Area ).

DBUA trace. log shows the following errors:

Exception in thread "AWT-EventQueue-0" java. lang. nullPointerExceptionat oracle. sysman. assistants. util. installUtils. compareVersion (InstallUtils. java: 266) --- pay attention to this line at oracle. sysman. assistants. util. asm. ASMUtils. validateDiskGroup (ASMUtils. java: 1154) at oracle. sysman. assistants. dbma. backend. cloneValidator. isDiskGroupCompatible (CloneValidator. java: 654) at oracle. sysman. assistants. dbma. backend. cloneValidator. isRecoveryAreaValidated (CloneValidator. java: 431) at oracle. sysman. assistants. dbma. ui. oracleBasePage. doNext (OracleBasePage. java: 956)

Cause:
While moving FRA to ASM disk, as a part of validation, DBUA compares disk group and RDBMS compatibilty. the validation fails with null pointer exception because the compatible parameter was not set in the pfile (or spfile) of the source database.

Solution:
Set the compatible parameter in the pfile of the source database as shown below and rerun DBUA.

compatible=x.x.0.0

Where x. x.0.0 is the value of the compatible parameter set in the source database.

For example, if the source database is 10.2.0.5 then it cocould be set:

compatible=10.2.0orcompatible=10.2.0.5