Frequent bpdbm <16> errors 'executing UPDATE DBM_MAIN.DBM)_ImageChangeLog'

[Anonymous]

Recently created bpdbm legacy debug log folder on my master and see regular entries of the following for ALL of my clients.

 02:44:33.545 [6322] <16> executeSql: Error executing UPDATE DBM_MAIN.DBM_ImageChangeLog SET Created DateTime = current utc timestamp  WHERE (MasterServerKey = 1000002) AND (BackupID = 'barney_1327459414') AND (ClientType = 0) AND (OperationID = 1) (rc=100) ErrMsg , ErrCode 0, SqlState

02:45:05.483 [6647] <16> executeSql: Error executing UPDATE DBM_MAIN.DBM_ImageChangeLog SET Created DateTime = current utc timestamp  WHERE (MasterServerKey = 1000002) AND (BackupID = 'fred_1327459036') AND (ClientType = 0) AND (OperationID = 1) (rc=100) ErrMsg , ErrCode 0, SqlState 

Have performed a nbdb_admin -validate -full and get a clean bill of health

Master:

VERSION NetBackup 7.1.0.3

Linux SUSE 11 x86_64

Just a bit concerning. A bug perhaps. Ignore them as the ErrCode is 0 ?

[Marianne]

Nothing easy when you post, Stuart!

Hopefully our Symantec BCE Martin will know...

Have you tried 'bpdbm -consistency 2' ?

[CRZ]

Any funky locale settings which might be messing about with the time and date format?

Probably not related, but any chance you're bitten by the "1 licensed processor" bug in 7.1.0.3?  (See TECH178219)

After applying the 7.1.0.3 upgrade, degraded performance may be seen in NetBackup and OpsCenter on Windows due to an unintentional CPU restriction imposed on the database.

 http://symantec.com/docs/TECH178219

[Anonymous]

@CRZ

No funky locale.

Its a linux master server - not a windows server which this technote says it only affects.

But I do have 4 physical CPU's

@Marianne

Can the consistency be run online.? Tried offline (netbackup shutdown) and taking a long time.... had to cancel to get daily backups going....

[Marianne]

As far as I know it can be executed with NBU online, but a quiet time should be chosen (no backups running).

Level 2 of consistency check does take a long time :

0 - A quick check of the NetBackup image database (the default).
1 - Performs more checks than the default check.
2 - The most in-depth consistency check. In addition to the level 0 and 1
checks, this level checks that the media that is mentioned in the image exists.
(That is, it cross-references the media servers databases.) On a large
NetBackup installation, the process takes much longer to complete than the
other checks.

[mph999]

As per Mariannes excellent post above, bpdbm -consistency 2 can be run with NBU running ...

M

[mph999]

02:45:05.483 [6647] <16> executeSql: Error executing UPDATE DBM_MAIN.DBM_ImageChangeLog SET Created DateTime = current utc timestamp  WHERE (MasterServerKey = 1000002) AND (BackupID = 'fred_1327459036') AND (ClientType = 0) AND (OperationID = 1) (rc=100) ErrMsg , ErrCode 0, SqlState 

Are all the errors related to clients that are ClientType = 0 ???

Martin

[mph999]

Looks like it is the multi-processor issue - the logs match previously seen issues.

M

[Anonymous]

How do i correlate my clients to being ClientType = 0 ?

Have a mixture of clients OS Type Windows , UNIX, other (as seen in Admin Console Host Properties > Clients)

Have also got Virtual Machine clients. All are reported in the above type <16> errors. No distinction.

Thanks

[Anonymous]

On UNIX/Linux:

/usr/openv/db/log/server.log

Started up NetBackup and output in the above file shows.

I. 02/09 10:28:27. SQL Anywhere Network Server Version 11.0.1.2645
I. 02/09 10:28:27. OEM Authenticated Edition, licensed only for use with authenticated OEM applications.
I. 02/09 10:28:27.
I. 02/09 10:28:27. Copyright (c) 2011, iAnywhere Solutions, Inc.
I. 02/09 10:28:27. Portions copyright (c) 2011, Sybase, Inc. All rights reserved.
I. 02/09 10:28:27. Use of this software is governed by the Sybase License Agreement. Refer to http://www.sybase.com/softwarelicenses
I. 02/09 10:28:27.
I. 02/09 10:28:27. 4 logical processor(s) on 1 physical processor(s) detected.
I. 02/09 10:28:27. Processor limit (licensed processors): 128
I. 02/09 10:28:27. Maximum number of physical processors the server will use: 1
I. 02/09 10:28:27. This server is licensed to:
I. 02/09 10:28:27.     NetBackup
I. 02/09 10:28:27.     Symantec Corporation
I. 02/09 10:28:27. Running Linux 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 on X86_64
I. 02/09 10:28:27. Server built for X86_64 processor architecture
I. 02/09 10:28:27. 25600K of memory used for caching
I. 02/09 10:28:27. Minimum cache size: 25600K, maximum cache size: 512000K
I. 02/09 10:28:27. Using a maximum page size of 4096 bytes
I. 02/09 10:28:27. Starting database "NBAZDB" (/usr/openv/db/data/NBAZDB.db) at Thu Feb 09 2012 10:28
I. 02/09 10:28:27. Starting database "NBDB" (/usr/openv/db/data/NBDB.db) at Thu Feb 09 2012 10:28
I. 02/09 10:28:27. Transaction log: /usr/openv/db/data/NBAZDB.log

[Mark_Solutions]

Can you run an All Log Entries report for a period of an hour or so when you know you are seeing the errors - just in case we can spot anything else

[CRZ]

I see a new Etrack opened earlier this week with a similar set of symptoms reported - 2684131 - and I think you should open a case, request an escalation and get attached to it...that is, if it's really bugging you.  (It sounds like you're not seeing the high CPU utilization that was reported in the other case?  There is one other difference - your server is SUSE and the Etrack was originally opened for a Windows server - but it's the same problem, namely lots of log entries reporting "executeSql: Error executing UPDATE DBM_MAIN.DBM_ImageChangeLog" despite an apparent successful finish)

Have your bpdbm log ready to move your case along to backline, then be ready for your backline engineer to request an EMM database dump (they'll tell you how).

[Will_Restore]

Any update on this?  I am seeing  <16> executeSql: Error message in bpdbm logs on 7.1.0.3 Unix Master.  Identical text except for client image name of course.  Not too worried but am curious as to the fix.

[Anonymous]

I will get back to looking if this still persists/exists.

I am still on 7.1.0.3 will update to 7.1.0.4 on the first available opportunity, and reply back here.

(thanks for reminding me of this.)