[cisco-voip] kErrorCDRFilesBackingUp - CDR flat files are backingup.

[Erick Bergquist]

Are you talking about the InsertCDR detailed trace or
a different log file?

The InsertCDR trace at time has a entry at 12:24am
about reading configurastion, then nothing until
12:34am which is the line about 10 minute timeout
occurred.

The CDR insert process is not stopping/starting by
itself as PID is same the past few days I've been
looking on this. I did restart the process once per
the workaround in the bug id mentioned below. PID has
been same since though.

Nothing in event logs (application, system, security)
at this time other then the database layer monitor
errors about CDR.  Is there some other SQL logs I
should be looking at?

The IPT SQL job runs at 1am daily. The first error
occurs before that job starts.

The Database Layer Monitor service maint period is at
24 hr and runs for 2 hours. 12am to 2am. 

The CDR load runs at 19:20 hours for 90 minutes
Uninhibited load from 18:20 hrs to 05:00 hrs

CDR database purge is set to auto purge after 120
days.

Someone in cisco discussion forums suggested I also
restart the database layer monitor service to try to
clear the problem. 

Should we maybe try adjusting time of database layer
maint period? so it doesn't run at same time as CDR
Load?

--- Wes Sisk <wsisk at cisco.com> wrote:
> Check the cdr insert log around that time. Looks
> like SQL may be dropping
> offline or too busy to process the cdr insert
> request.  could be the service
> stopping i guess.  make sure the PID does not change
> day to day for
> cdrinsert.  any change would reflect a crash or
> service restart for some
> reason.  check the SQL server logs around that time
> and see if it reported
> any events.
> 
> this may be due to the IPT optimization job running,
> or the CDR purge
> process running.  the 1st is a job in sql - when is
> it scheduled to run?
> The 2nd is done by database layer monitor and timing
> is set by the dblm
> service parameters.  what time is it set to run?
> 
> on that same line the ART cdr purge could cause the
> same issue.  is ART/CAR
> configured to purge the CDR database and if so, what
> time?
> 
> /Wes
> 
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net]On Behalf
> Of Erick Bergquist
> Sent: Thursday, May 19, 2005 10:16 PM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] kErrorCDRFilesBackingUp - CDR
> flat files are
> backingup.
> 
> 
> Hi,
> 
> Has anyone had the below in Application event log
> and
> know a fix for issue? I found a bug id that matches
> on
> this (CSCeg37424) but the workaround is not working.
> 
> The InsertCDR detailed trace is turned on and the
> error happens at 12:24am and the entry in trace file
> is at 12:34am saying 10 minute timeout occurred.
> Nothing in trace between 12:24 and 12:34.
> 
> Issue was found in CCM 4.0(1)ES 17.1 and marked as
> unreproducable.  This is on Call Manager
> 4.0(2a)Sr1a.
> 
> Workaround from bug id is to kill the insertcdr
> process using c:\utils\kill command then restart the
> CDR insert service.
> 
> These errors are occuring at 12:24am and 1:24am
> nightly like clockwork. Not during day and CDR is
> working fine. BARS runs earlier before midnight.
> There
> are no CDR flat files in the CDR folder either. They
> show up briefly then get inserted and deleted. We
> have
> a few files in the bad folder but not from this time
> period. Maybe 1-2 bad cdr flat files a day.
> 
> 
> Event Type:	Error
> Event Source:	Cisco Database Layer Monitor
> Event Category:	None
> Event ID:	3
> Date:		5/18/2005
> Time:		1:24:32 AM
> User:		N/A
> Computer:	CCM1
> Description:
> Error: kErrorCDRFilesBackingUp - CDR flat files are
> backing up.
>   App ID: Cisco Database Layer Monitor
>   Cluster ID: CCM1-Cluster
>   Node ID: 172.16.2.20
> Explanation: CDR flat files are not being removed. 
> On
> the primary CDR
> server, verify that the InsertCDR service is running
> and properly
> configured. On a server not the primary, verify that
> the location for
> collecting CDR files is accessible via the network.
> Recommended Action: Set trace for InsertCDR service
> to
> detailed and
> look
> for errors in the trace.  Check enterprise CDR
> parameters for
> accuracy..
> 
> 
> 
> 
> __________________________________
> Yahoo! Mail Mobile
> Take Yahoo! Mail with you! Check email on your
> mobile phone.
> http://mobile.yahoo.com/learn/mail
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> 


		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail