Home Discussions Questions & Answers Adop fs_clone is stuck and hanging for hours

Adop fs_clone is stuck and hanging for hours

Avatar photoCustomer December 12, 2020 at 10:51 am

We are executing an `adop phase=fs_clone` during our EBS 12.2 maintenance cycle, and the process has become stuck and hanging for hours without any diagnostic messages. Standard tools like `adopscanlog` haven’t helped. What are the general debugging strategies for this scenario?

Viewing 10 reply threads
  • Author
    Replies
    • Support December 13, 2020 at 9:07 pm  

      A stuck `adop phase=fs_clone` with no errors in the log files can be highly frustrating. General debugging often involves checking critical system components outside the main log, such as ensuring all relevant services and connections are properly configured, and reviewing low-level database or OS logs for silent failures.

    • Avatar photoCustomer December 14, 2020 at 3:58 pm  

      We previously faced issues during an upgrade (12.2.8 to 12.2.9) where patch application stalled due to service name configurations and issues related to `adgrant.sql`. Could misconfiguration of FND_NODES or service names be a related cause?

    • Support December 15, 2020 at 8:38 am  

      Yes, complex issues during upgrade phases like applying patches (e.g., patch 28840850) often point to environmental inconsistencies. It is crucial to verify the settings using SQL queries to check the `fnd_nodes` table to confirm service names, webhost, and domain information are correctly defined for the DB, CP, Admin, Forms, and Web components.

    • Avatar photoCustomer December 16, 2020 at 1:11 am  

      What query should we run as the APPS user to quickly gather this necessary FND_NODES diagnostic information?

    • Support December 18, 2020 at 3:45 am  

      You should run the following diagnostic query as APPS, ensuring proper formatting: `select support_db D, support_cp C, support_admin A, support_forms F, support_web W, node_name, webhost from apps.fnd_nodes order by node_id;`.

    • Avatar photoCustomer December 18, 2020 at 4:27 pm  

      If we identify critical patches that failed or are missing, how can we quickly verify their status without manually checking the patch history table?

    • Support December 19, 2020 at 5:51 am  

      You can use a custom Blitz Report built around the `AD_PATCH.IS_PATCH_APPLIED` function to check patch status efficiently. This simplifies the verification process for patches like the AD and TXK deltas necessary for upgrades.

    • Avatar photoCustomer December 20, 2020 at 10:57 am  

      We also need rapid access to standard performance metrics like AWR reports during this troubleshooting phase. Can Blitz Report help centralize these DBA utilities?

    • Support December 21, 2020 at 12:06 pm  

      Absolutely. Blitz Report helps by Simplifying DBA tasks. It allows DBAs to quickly execute performance diagnostic queries, including AWR reports (even in multitenant environments), directly from the EBS interface without switching tools or logging in via SQL*Plus.

    • Avatar photoCustomer December 22, 2020 at 2:36 am  

      If the issue is related to cached objects preventing the clone, can Blitz Report access the relevant procedure to clear the EBS cache?

    • Support December 22, 2020 at 6:03 pm  

      If EBS cache clearing is required, the standard method involves using specific procedures referenced in Oracle documentation (like that mentioned in ). While Blitz Report specializes in reporting, having diagnostic tools readily available allows for quick identification of cache-related issues before manually executing the required cache-clearing script.

Viewing 10 reply threads
  • You must be logged in to reply to this post.

Login with: