Data Loss Prevention

Hi everybody

I recently tried to upgrade our productive DLP environment (1 Enforce, 1 Endpoint Prevent, 1 Oracle-DB).
Unfortunately, the upgrade suffered a deadlock on the Oracle-part (Upgrading Statistics, at 95,5% of the Overall DB-Upgrade Progress :D ).

The Upgrade was meant to be from v11.0 to 11.6.0.

Fortunately, I got an Oracle backup made from the DBAs just before the upgrade.

Following has been written to the trace file:

*** 2014-07-24 17:16:54.445
*** SESSION ID:(589.24727) 2014-07-24 17:16:54.450
*** CLIENT ID:(Upgrade Schemas) 2014-07-24 17:16:54.450
*** SERVICE NAME:(SYS$USERS) 2014-07-24 17:16:54.450
*** MODULE NAME:(Vontu v11_6_0 Schema Upgrader) 2014-07-24 17:16:54.450
*** ACTION NAME:(Upgrade Schemas) 2014-07-24 17:16:54.450
 
kdccak: retry_cnt_fuk > KDC_FUK_RET
kdccak: retry_cnt_fuk > KDC_FUK_RET

*** 2014-07-24 17:19:00.649
*** CLIENT ID:(Refresh Statistics) 2014-07-24 17:19:00.654
*** MODULE NAME:(Vontu v11_6_0 Schema Upgrader) 2014-07-24 17:19:00.654
*** ACTION NAME:(Refresh Statistics) 2014-07-24 17:19:00.654
 

*** 2014-07-24 17:19:00.685
DEADLOCK DETECTED ( ORA-00060 )
 
[Transaction Deadlock]
 
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
 
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-00020000-00000eff        27     589     X             27     589           S
 
session 589: DID 0001-001B-00000C0D session 589: DID 0001-001B-00000C0D
 
Rows waited on:
  Session 589: no row
 
----- Information for the OTHER waiting sessions -----
----- End of information for the OTHER waiting sessions -----
 
Information for THIS session:
 
----- Current SQL Statement for this session (sql_id=drwfb013vmtn4) -----
INSERT INTO SYS.JOB$ (JOB, LOWNER, POWNER, COWNER, NEXT_DATE, INTERVAL#, FLAG, WHAT, NLSENV, ENV) VALUES (:B10 , :B9 , :B8 , :B7 , :B6 , NVL( :B5 , 'null'), :B4 , :B3 , :B2 , :B1 )
----- PL/SQL Stack -----
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
c0000004fc7436c0       290  package body SYS.DBMS_IJOB
c0000004987fe6e8       159  package body SYS.DBMS_JOB
c0000004fc93cbc0      5253  package body PROTECT.UPGRADESCHEMA_V11_6_0
c0000004fc93cbc0      4729  package body PROTECT.UPGRADESCHEMA_V11_6_0
c0000004fc93cbc0      1592  package body PROTECT.UPGRADESCHEMA_V11_6_0
c00000049874e120         1  anonymous block
===================================================

Surely, the Services havent been started up since.

Now my question is the following:

Is the DB gone for good and the only possible path is to restore the backup, or may I try again to upgrade after restarting the DB?

Well well ... After restoring the DB and trying again, same message.
No open connections to the DB whatsoever, besides the updater.

It seems like the updater process is blocking himself. Does this make ANY sense at all?

Did you purhase your Oracle through Symantec and have mainteance and support through them?  If so I would open up a support ticket (www.mysymantec.com) or call them to have this fiugred out

Yes, we do. I am already struggling through the whole support process to open a ticket.

Since support is not really helpful on this one, I am trying my luck in here:

Does anyone know how the task "Refresh Statistics" during the DB Upgrade may be skipped?

I know there is a possibility to do so (sidenote from Support):

"... There is a solution (42963) that describes how to skip this task and cut to the chase, but it is strongly advised that this task happen as part of the course of the upgrade. ..."

Since the task "Refresh Statistics" seems mainly to be carrying out some Oracle CBO-Routines, it would be absolutely no hassle to do this after the upgrade. Yes, we are aware of the fact that the performance might be affected if not done, but on a DB with the size of about 15GB, this is marginal.