Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com
http://www.free-online-exams.com
Problem: Adpatch Fails With ORA-12505 Error In RAC Environment On R12
Symptoms:
Migrating to RAC
When applying a patch workers connecting using thin JDBC - like for loadjava and akload jobs - fail with error
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
Solution:
This error occurs because the JDBC connect string used by adpatch does not point to a SID but to a servicename, and adpatch cannot connect with it in all cases.
Solution
Workaround:
1.
Create a custom TNS alias in the $TNS_ADMIN/__ifile.ora :
(replace host.domain, port-nr and instance1 with the actual values)
PATCHSID=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=host.domain)(PORT=port-nr))
(CONNECT_DATA=(SID=instance1))
)
2.
Before each adpatch, and after having run the Applications environment file, set the TWO_TASK environment variable to point to the alias created in step 1:
export TWO_TASK=PATCHSID
Fix:
________________________________________
Please note the following important information when using multiple instance simultaneously for patching:
In this release adpatch has not yet been optimized for this, and using more instances for patching might show it:
• Does not scale well
• Can lead to contention during dictionary updates as well as transaction data updates
• Can even cause performance degradation
Due to the above mentioned concerns, it is not recommended to use multiple RAC instances for patching. In case this use introduces issues it might be required to revert back to using a single instance when patching. This can be achieved by using the above workaround and inserting the following command in file $APPL_TOP/custom$CONTEXT_NAME.env :
export AD_APPS_JDBC_URL=
"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=.)(PORT=)))(CONNECT_DATA=(SID=)))"
Note: Having too many instances specified in AD_APPS_JDBC_URL might for some adpatch worker jobs lead to error "string beginning "(DESCRIPTI..." is too long. maximum size is 239 characters.". This is because of a limitation in SQL*Plus where the connect string length can not exceed 239 characters. In that case the length of AD_APPS_JDBC_URL needs to be reduced by setting it to less - maybe even one - instances for patching to work properly.
________________________________________
Apply the following 2 patches:
Patch 7491048 introduces a new environment variable named "AD_APPS_JDBC_URL" to be used by the AD utilities to make them work in a RAC environment.
Patch 6810458 "AD JAVA UTILITIES SHOULD USE S_APPS_JDBC_CONNECT DESCRIPTOR TO CONNECT TO D/B" provides the fix in adpatch
References:
Adpatch Fails With ORA-12505 Error In RAC Environment On R12 [ID 742371.1]
BUG:6768619 - WRONG CONNECT STRING GENERATED BY OCM
PATCH:6810458 - AD JAVA UTILITIES SHOULD USE S_APPS_JDBC_CONNECT DESCRIPTOR TO CONNECT TO D/B
PATCH:7491048 - BACKWORDPORT OF BUG:6768619:WRONG CONNECT STRING GENERATED BY OCM
Symptoms:
Migrating to RAC
When applying a patch workers connecting using thin JDBC - like for loadjava and akload jobs - fail with error
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
Solution:
This error occurs because the JDBC connect string used by adpatch does not point to a SID but to a servicename, and adpatch cannot connect with it in all cases.
Solution
Workaround:
1.
Create a custom TNS alias in the $TNS_ADMIN/
(replace host.domain, port-nr and instance1 with the actual values)
PATCHSID=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=host.domain)(PORT=port-nr))
(CONNECT_DATA=(SID=instance1))
)
2.
Before each adpatch, and after having run the Applications environment file, set the TWO_TASK environment variable to point to the alias created in step 1:
export TWO_TASK=PATCHSID
Fix:
________________________________________
Please note the following important information when using multiple instance simultaneously for patching:
In this release adpatch has not yet been optimized for this, and using more instances for patching might show it:
• Does not scale well
• Can lead to contention during dictionary updates as well as transaction data updates
• Can even cause performance degradation
Due to the above mentioned concerns, it is not recommended to use multiple RAC instances for patching. In case this use introduces issues it might be required to revert back to using a single instance when patching. This can be achieved by using the above workaround and inserting the following command in file $APPL_TOP/custom$CONTEXT_NAME.env :
export AD_APPS_JDBC_URL=
"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=
Note: Having too many instances specified in AD_APPS_JDBC_URL might for some adpatch worker jobs lead to error "string beginning "(DESCRIPTI..." is too long. maximum size is 239 characters.". This is because of a limitation in SQL*Plus where the connect string length can not exceed 239 characters. In that case the length of AD_APPS_JDBC_URL needs to be reduced by setting it to less - maybe even one - instances for patching to work properly.
________________________________________
Apply the following 2 patches:
Patch 7491048 introduces a new environment variable named "AD_APPS_JDBC_URL" to be used by the AD utilities to make them work in a RAC environment.
Patch 6810458 "AD JAVA UTILITIES SHOULD USE S_APPS_JDBC_CONNECT DESCRIPTOR TO CONNECT TO D/B" provides the fix in adpatch
References:
Adpatch Fails With ORA-12505 Error In RAC Environment On R12 [ID 742371.1]
BUG:6768619 - WRONG CONNECT STRING GENERATED BY OCM
PATCH:6810458 - AD JAVA UTILITIES SHOULD USE S_APPS_JDBC_CONNECT DESCRIPTOR TO CONNECT TO D/B
PATCH:7491048 - BACKWORDPORT OF BUG:6768619:WRONG CONNECT STRING GENERATED BY OCM
No comments:
Post a Comment