Article Original Creation Date: 2012-02-03

Overview

We are currently upgrading new ADSL costumers during the night instead of during installation time. The policy finds about 15000 costumers to upgrade but only processes 300-400. The job is called "TDC Timer, natopgradering af 3DK04-02 til 7AH046, sru" in TDC realm. The logging says that 300-400 succed, 100 skipped and 900 failed, but we are unable to see the failed in detail as they are not showing in the log. Can you please investigate why the ACS cannot process more.

Environment

 

Root Cause

Hi All,

 

 

This is a follow up of my previous questions regarding this Timer based policy problem.

 

Meanwhile I gathered extra information out of a third log capture of a third runtime of that policy.

 

TDC uses SG4.1.1.

 

Policy runs from 02:00-05:00 am  150/30 concurrency limit/rate target, a HW/FW is used as filter resulting in 14K devices to be executed by that policy.

 

 

Looking at the results of the last run I investigated see attached screenshot:

 

Checking the Encore.logs shows me these kind of messages, I calculated out of that the total amount of possible starts of executed devices:

 

[Policy:

name=TDC

Timer

natopgradering

af

3DK04-02

til

7AH046

sru

guid=9ee75c0c-4027-11e1-a35f-511f3a0dc9ab]

This

policy

has

a

total

of

30

devices

to

process.

[Policy:

name=TDC

Timer

natopgradering

af

3DK04-02

til

7AH046

sru

guid=9ee75c0c-4027-11e1-a35f-511f3a0dc9ab]

This

policy

has

a

total

of

3

devices

to

process.

[Policy:

name=TDC

Timer

natopgradering

af

3DK04-02

til

7AH046

sru

guid=9ee75c0c-4027-11e1-a35f-511f3a0dc9ab]

This

policy

has

a

total

of

30

devices

to

process.

[Policy:

name=TDC

Timer

natopgradering

af

3DK04-02

til

7AH046

sru

guid=9ee75c0c-4027-11e1-a35f-511f3a0dc9ab]

This

policy

has

a

total

of

8

devices

to

process.

[Policy:

name=TDC

Timer

natopgradering

af

3DK04-02

til

7AH046

sru

guid=9ee75c0c-4027-11e1-a35f-511f3a0dc9ab]

This

policy

has

a

total

of

27

devices

to

process.

[Policy:

name=TDC

Timer

natopgradering

af

3DK04-02

til

7AH046

sru

guid=9ee75c0c-4027-11e1-a35f-511f3a0dc9ab]

This

policy

has

a

total

of

4

devices

to

process.

Total count is 1270 devices.

 

Further I counted the message: published to JMS queue = 259

 

Status is succeeded = 200

 

Status is skipped = 58

 

Status is Failed = 1

 

As you might notice the failure count in the GUI policy logging shows 1012 devices.  1270-(200+58)=1012

 

Counting the number of uniqueID’s in relationship with this Policy shows me a count of 507

 

 

The only related error I notice in the Encore.log’s that only shows up during the runtime of this particular Policy is:

 

2012-02-02 03:27:57,899 ERROR        servicegateway.policy - class: PolicyExecutionManager method: executePolicies: 10046 - Error executing policy (name=TDC Timer, natopgradering af 3DK04-02 til 7AH046, sru): DB error adding device history for policy with GUID='9ee75c0c-4027-11e1-a35f-511f3a0dc9ab': com.supportsoft.encore.common.exception.DAOException: java.sql.SQLException: ORA-01400: cannot insert NULL into ("SG_USER"."SPRT_SG_POLICY_DEVICE_HISTORY"."IP_ADDRESS")

 

This error shows up 91 times in relationship with this policy.

 

 

Questions,

 

1)     What could cause the difference in started requests to devices: 1270 could be started but I only notice 507 uniqueID’s from which only 259 are really executed.

 

2)     Why is there a big difference in count of the Failed devices form the policy logging and the actual logging, a different calculation is used here I guess.

 

3)     What could cause the error and could it impact the start of that many devices in comparison of the amount of errors shown (91 versus 1270 –507=763 )

  

Resolution

The in the cause mentioned ERROR: ORA-01400; cannot insert NULL into ("SG_USER"."SPRT_SG_POLICY_DEVICE_HISTORY"."IP_ADDRESS") is caused by a bug introduced in SG4.1 upgrade and solved in SG4.1.2.
EE 23850 - Error: cannot insert NULL in SPRT_SG_POLICY_DEVICE_HISTORY.IP_ADDRESS

 

 

The policy history was not permitting records to be stored without an IP

 

address.  Running a policy against a device that did not have an IP address

 

resulted in an error.  Policy history no longer requires an IP address.
 

The DDL statement in the 4.1.2 upgrade you can run now is:

 

 

ALTER TABLE SPRT_SG_POLICY_DEVICE_HISTORY MODIFY IP_ADDRESS varchar2(39) NULL;
 
We will have to wait after the above implementation if the policy processes normal again!!(02-15-2012)
Document Links
https://support.avolin.com/hc/en-us/articles/360015007974-Cannot-insert-NULL-in-SPRT-SG-POLICY-DEVICE-HISTORY-IP-ADDRESS-error-Internal