• Home
• Before you begin
• Provisioning
• Lockdown Profiles
• Application Containers

Application Containers

Lab 10: Diagnosing and Correcting Problems, and Restarting Sync

Overview

In Lab10 we explore the restartability of the patching process. To demonstrate this, we do the following:

1. Deliberately make a manual change to NYC that will conflict with applying patch 301.
2. Attempt to sync NYC to apply the patch – anticipating a failure.
3. Query relevant DBA views to identify the problem.
4. Resolve the problem and re-start the sync, which should now succeed.

Execution

• Open a terminal window
• Change directory to /u01/HOL/app_containers/
• source the environment. At command prompt execute source cdb1.env
• sqlplus /nolog
• At the SQL prompt execute SQL>@10.Diagnose_Restart.sql

Review of Application Container Lab10:

In this lab, we diagnosed a problem in applying a patch, resolved it, and successfully restarted the patch application process. The detailed steps were:

1. Deliberately make a manual change to NYC that will conflict with applying patch 301.
2. Attempt to sync NYC to apply the patch – anticipating a failure.
3. Query relevant DBA views to identify the problem.
4. Resolve the problem and re-start the sync, which now succeeded.

Detailed Steps

Phase 1. Manual change in NYC.

Here, we have deliberately added an index in NYC that we know will clash with patch 301. In the next step we're going to apply that patch, to observe the conflict.

Phase 2. Sync Application PDB for franchise / tenant NYC to apply patch.

The patch application failed, with error message

ORA-00955: name is already used by an existing object

In the previous lab we learned about some of the DBA views that are relevant to Application Container. Let's use that knowledge to pinpoint the specific problem encountered here.

Phase 3. Diagnose the problem.

So the failure was in step 2 – adding the index. As expected, this failed, because the index already exists in this PDB. We have to fix this problem before we can proceed.

Phase 4. Fix the problem and restart the patch application.

The appropriate fix in this case is to drop the locally-created index. We'll do that, and then attempt to re-apply the patch. This time, the patch applied successfully. Recall again, however, the sequence of operations in Patch 301.

1.     Add column wm_Orders.Financial_Quarter_Code.

2.     Create index wm_Orders_M1 on wm_Orders.

3.     Add rows to wm_List_of_Values.

4.     Update orders to specify the appropriate financial quarter.

It's important to note that it was the second step that failed. The first had already succeeded. All we did was to restart the patch application. However, the previous failed partial patch application was recorded with enough information to know at which point to resume. This is why the second attempt to apply the patch succeeded (and did not fail at step 1 because the column created in that step already exists).

Click Here to Go to Lab 11